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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3 GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following definitions apply: 

Codec: device to encode information from its original representation into an encoded form and to decode encoded 
information into its original representation 

Codec Lists, Selected Codecs: The OoBTC procedures pass a number of codec lists created by comparing the 
capabilities of the different nodes or equipment involved. For the different interfaces involved during call setup, 
handover, and relocation, the following codec lists and selected codecs need to be distinguished - where codec lists are 
ordered, "ordered" is included in the description: 

i) Supported Codecs List (DTAP) - this is the list of codecs supported by the UE. It is subdivided into codecs 

supported for the currently used radio access and codecs that can be used for other radio accesses supported 
by the UE. The list contains only the codec types, but not the individual configuration, as the UE is 
mandated to support all configurations for a given codec type. 

ii) Supported Codecs List (BSSMAP) - "BSC-SCL" - this is the Hst of codecs supported by the ESS (BSS- 

SCL). The list contains the codec types as well as the individual codec configurations supported by the 
radio access at the very moment of call setup. 

iii) Supported Codecs List (BICC) - this ordered Hst is used on NNI (BICC) OoBTC signalHng. At call setup it 

is sent forward by the node originating the OoBTC signalling and contains the default PCM codec and a set 
of codecs that is common to the nodes and the equipment involved in setting up the call. For a mobile 
originating call, these are the UE and the MGWs involved in the connection and, for UTRAN, GERAN lu- 
mode and GERAN AoIP mode, also the originating radio access. At inter-MSC relocation and inter-MSC 
handover, the Supported Codecs List (BICC) is sent forward by the anchor MSC towards the target MSC 
and contains the default PCM codec and a set of codecs that is common to the anchor MSC and the nodes 
involved in setting up the new call leg towards the target MSC. For UDI/RDI multimedia calls with 
fallback and service change according to 3GPP TS 23.172 [17], the multimedia dummy codec will be 
included (see 3GPP TS 26.103 [5]). 

iv) Available Codecs List (BICC) - this is the list of codecs available for the NNI connection. It is returned in 

the backward signalling to the node that originated the OoBTC and is a subset of the Supported Codecs List 
(BICC) sent forward. At call setup the Available Codecs List (BICC) contains the default PCM codec and a 
common set of codecs that can be supported by all nodes and, if Transcoder Free Operation has been 



ETSI 



3GPP TS 23.153 version 9.1.0 Release 9 9 ETSI TS 123 153 V9.1.0 (2011-01) 

achieved end-to-end, also by the UEs and the radio access networks that are involved in the call. At inter- 
MSC relocation and inter-MSC handover to UMTS, the Available Codecs List (BICC) contains the default 
PCM codec and a set of codecs that can be supported by all nodes involved in setting up the new call leg 
towards the target MSC and, if Transcoder Free Operation can be maintained end-to-end after the handover 
or relocation, also by the UE and the target radio access network. 

v) Selected Codec (BICC) - this is the codec selected to be used on the NNI connection. It is one of the 

codecs contained in the Available Codecs List (BICC) and may be different from the codec that is used on 
the radio interface, but if end-to-end Transcoder Free Operation has been achieved, this will be the 
common codec for all nodes, the UEs, and the radio accesses. 

vi) lu-Supported Codecs List (MAP) - this ordered list is used for MAP signalling from the anchor MSC to the 

target MSC. It is subdivided into lists for UTRAN and GERAN lu-mode and contains the codecs common 
to the UE and to the anchor MGW for each radio access supported by the UE. The codec capabilities of the 
serving radio access, i.e. the radio access used prior to the inter-MSC handover or relocation, are not taken 
into account. Codecs that are only applicable to the NNI, e.g. the default PCM codec or the multimedia 
dummy codec (see 3GPP TS 26.103 [5]), are not included. 

vii) lu- Available Codecs List (MAP) - this is the list of codecs available for the target lu interface. When 

returned by the target MSC to the anchor MSC in response to an initial Prepare Handover message it is the 
lu-Supported Codecs List (MAP) reduced according to the capabilites of the target MGW and the target 
radio access. After a subsequent intra-MSC handover or relocation, the target MSC may update the lu- 
Available Codecs List (MAP) according to the capabilites of its associated MGW and the new target radio 
access, if necessary. 

viii) lu-Selected Codec (MAP) - this is the codec selected for the target lu interface. It is one of the codecs 

contained in the lu- Available Codecs List (MAP). In response to a Prepare Handover request message this 
is the codec selected by the target MSC and indicated back to the anchor MSC. When sent from the anchor 
MSC in a Forward Access Signalling request message during a codec modification, it contains the codec 
type and configuration chosen by the anchor MSC. 

ix) lu-Currently Used Codec (MAP) - this is the codec in use on the serving lu interface prior to an inter-MSC 

handover. 

x) TFO Codec List (H.248) - this is the list of codecs for use by the MGW during TFO in-band negotiations 

with a distant node. The list is passed via the Mc interface from the server to the MGW. The first entry of 
the TFO Codec List (H.248) is to be used by the MGW as the 'Local Used Codec' (see [10]). 

xi) Distant Codec List (H.248) - this is the list of codecs received by the MGW from a distant node during 

TFO in-band negotiations. The list is passed via the Mc interface from the MGW to the server. The first 
entry of the Distant Codec List (H.248) is the 'Distant Used Codec' received by the MGW (see [10]). 

xii) Codec (H.248) - this is the codec for use on a certain MGW termination. It is passed via the Mc interface 

from the server to the MGW. 

xiii) MSC Preferred Codec List (BSSMAP) - "MSC-PCL" - this is the Hst of codecs supported by both the MSC 
and the MS as allowed by the MSC for this assignment or handover, ordered by the MSC with the most 
preferred Codec Types first (e.g. the ones that may enable TrFO or TFO). 

xiv) AoIP-Supported Codecs List (Anchor) (MAP) - this ordered list is used for MAP signalling from the 

anchor MSC to the target MSC if anchor MSC supports GERAN AoIP mode. It contains codecs supported 
by the UE and by the anchor MSC for GSM access. Codecs that are only applicable to the NNI, e.g. the 
default PCM codec or the CSData Dummy Codec (see 3GPP TS 26.103 [5]), are not included. 

xv) AoIP-Selected Codec (Target) (MAP) - the codec selected by the target BSS, to be used by the UE/MS in 

GERAN A/Gb mode after the handover to the BSS using A interface over IP. This is the Speech Codec 
(BSS chosen) as returned by the Target BSS in BSSAP. 

xvi) AoIP- Available Codecs List (MAP) - a list of codecs for GERAN A/Gb mode available for the target AoIP 
interface signalled via MAP. This is the Codec List (BSS Supported) returned by the Target BSS in BSSAP 
reduced according to the capabilities of the Target MSC. 

Within the ordered codec lists, the codecs are ordered in decreasing order of priority, the first entry in the list being the 
highest priority codec (preferred codec). 
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Tandem Free Operation: configuration of a connection with two transcoders that support TFO protocol and whose 
external coding schemes are compatible, thus enabling compressed speech to pass between them 

NOTE 1 : When the TFO protocol is not supported by both transcoders or the coding schemes are not compatible 
then normal "Tandem" operation occurs and PCM encoded speech is passed between them. 

Transcoder: device to change the encoding of information from one particular encoding scheme to a different one, 
most commonly to/from a compressed speech algorithm from/to PCM. 

Transcoder Free Operation: configuration of a speech or multimedia call for which no transcoder device is physically 
present in the communication path and hence no control or conversion or other functions can be associated with it 

Out of Band Transcoder Control: capability of a system to negotiate the types of codecs and codec modes on a call 
per call basis through out-of-band signalling, required to establish Transcoder Free Operation. 

Default PCM Codec: network default 64kb/s codec for speech in PCM domain 

NOTE 2: For example ITU G.71 1 A-law. 

Transcoding free link (TrFL): bearer link, where compressed voice is being carried between bearer endpoints 

NOTE 3: Within the UMTS network, the compressed voice is transmitted in lu/ Nb User Plane format, depending 
on the related interface. 

Tandem free link (TFOL): bearer link between transcoders that are operating in Tandem Free Operation mode, i.e. 
bypassing the transcoding functions 

NOTE 4: The involved transcoders can be a UMTS transcoder or a GSM TRAU with TFO functionality. 

Transcoder free operation (TrFO): calls that have no transcoders involved in the connection between the source 
codecs 

NOTE 5: For mobile to mobile calls this is UE to UE, although the connection could be UE to another type of 
terminal. TrFO operation is considered a concatenation of TrFLs between RNCs. 

NOTE 6: In case of mobile to fixed network calls the term "Transcoder free operation" is applicable for the TrFLs 
carrying compressed speech. The TrFO usually ends at the Gateway to the PSTN where the speech is 
transcoded e.g. to G.711. 

Tandem free and Transcoding free operation (TaTrFO): concatenation of "transcoding free links" and "tandem free 
links" 

lu Framing: framing protocol used for the speech packets on both the lu User Plane interface and the Nb User Plane 
interface 

NOTE 7: The lu framing protocol is specified by [4]. 

In addition, the definitions of ACS, SCS, OM, and MACS provided in [5] apply. 

Direct Codec: is a codec that can be used without any additional transcoding stage inserted at the MGW that is offering 
the codec list. E.g., a direct codec can be AMR or another mobile codec when the end terminal is a mobile station, or 
G.71 1 when interworking with the PSTN. 

Indirect Codec: is a codec that requires transcoding at the MGW providing the codec list. 

Auxiliary RTP payload type: is a payload type used in combination with a speech codec to transmit some non-spech 
audio via RTP. The Telephony Event RTP Payload Type and the , Comfort Noise Codec are the only "Auxiliary" RTP 
payload type defined in the present Release. 
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3.2 Abbreviations 

For the purposes of the present document, the abbreviations defined in GSM 01.04 and the following apply: 

ACS Active Codec mode Set 

APM Application Transport Mechanism 

BC Bearer Control 

BICC Bearer Independent Call Control 

CC Call Control 

CCD Conference Call Device 

CFNRc Call Forward Not Reachable 

CFNRy Call Forward on No Reply 

IN Intelligent Network 

luFP lu Framing Protocol 

MACS Maximal number of codec modes in the ACS 

OM Optimization Mode 

OoBTC Out-of-Band Transcoder Control 

QoS Quality of Service 

RAB Radio Access Bearer 

SCS Supported Codec mode Set 

TFO Tandem Free Operation 

TICC Transport Independent Call Control 

TrFO Transcoder Free Operation 

UP User Plane 



4 Out-of-Band Transcoder control functionality 

Cellular networks depend heavily on codecs to provide their services. Codecs are necessary to compress speech in order 
to utilise efficiently the expensive bandwidth resources both in the radio interface and in the transmission networks. 

Unnecessary transcoding of speech significantly degrades quality and, therefore, cellular systems try to avoid it for 
mobile-to-mobile calls when both UEs and the network support a common codec type. 

Although the main reason for avoiding transcoding in mobile-to-mobile calls has been speech quality, the transmission 
of compressed information in the CN and CN-CN interface of the cellular network also offers the possibility of 
bandwidth savings. Therefore Out-of-Band Transcoder Control is not limited to mobile-to -mobile calls but can be 
applied for calls to or from an external network as well. 

Digital cellular systems support an increasing number of codec types. As a result, in order to allocate transcoders for a 
call inside the network, and to select the appropriate codec type inside the UEs, signalling procedures are defined to 
convey the codec type selected for a call to all the affected nodes (UEs and (potential) transcoding points inside the 
network). Also, codec negotiation capabilities are being defined to enable the selection of a codec type supported in all 
the affected nodes, i.e. to resolve codec mismatch situations. This codec negotiation maximises the chances of operating 
in compressed mode end-to-end for mobile-to-mobile calls. 

To allow transport of information in a compressed way in transmission networks, these networks make use of the 
transport -independent call control protocol as specified in [8] that provides means for signalling codec information, 
negotiation and selection of codecs end-to-end. 

4.1 OoBTC Requirements 

The OoBTC mechanism shall support the following: 

- The capability to negotiate the preferred codec type to be used between two end nodes and to avoid the use of 
transcoders in the network at call set-up. 

The originating UE indicates the list of its supported codec types for codec negotiation. This list shall be conveyed to 
the terminating MSC. The terminating UE indicates its list of supported codec types to the terminating MSC. The 
terminating MSC shall convey the selected codec to the originating MSC, which then indicates the selected codec to the 
originating UE. 
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Where no compatible codec type can be selected between the UEs then the default PCM coding shall be selected. 
Therefore, the default PCM codec shall always be included in the codec list for OoBTC. The originating MSC shall 
insert a transcoder in the path from the originating UE. Codec selection for the terminating UE is then performed within 
the terminating MSC, independently of the originating MSC. 

NOTE: For a codec type supporting various modes, the described functionality shall also be applicable to 

negotiate the set of codec modes common to originating and terminating UEs. Other negotiations such as 
Initialisation and Rate control are performed at a later point in time by the lu framing protocol. 

- The capability to control the presence of transcoders in the network after call set-up. 

Where a change to the call state of a transcoder free connection occurs, such that compressed speech cannot be 
maintained, it shall be possible to insert a transcoder or pair of transcoders where needed in the path. If this results in 
change to the encoding of the speech in other nodes then it shall be possible to inform the end points of this segment 
that the speech coding is changed. Such examples where this could occur are: 

- SS interruptions (e.g. A to B call connection becomes to multiparty call connection.) 

- Handover to an incompatible partner. 

- Synchronisation loss 

Where a change in call state as described above is temporary then it shall be possible to return to a transcoder free 
connection by removing the inserted transcoders and informing the endpoints that the connection has resumed to 
compressed speech encoding. 

- The codec types comprise codecs for speech in the first phase of the present document. The transcoder control 
should have enough expandability to support future enhancements of codec types. 

- The transcoder control procedure shall not cause a perceivable time lag in the cases of establishing transcoder 
free connection and reverting to normal (double transcoded) call connection in the cases described above for 
control of the presence of transcoders. 

- The capability to insert transcoder (in cases where a TrFO connection is not possible) at the most appropriate 
location, i.e. to save bandwidth it should be located at the CN edge between an ATM or IP transport network and 
a STM network. When Transcoders are inserted, the OoBTC procedures shall provide support for TFO for 
inband codec negotiation and transmission of compressed speech. 

When a transport network cannot maintain compressed voice then reversion to the default PCM coding shall 
occur. A transcoder shall be inserted at that point and OoBTC procedures terminated. TrFO link is then 
possible between that point and the preceding nodes. 

When a Non-TrFO call reaches the UMTS CN then OoBTC procedures are initiated from that point and after 
codec negotiation has been performed, if compressed voice can be supported through the CN then a 
transcoder is inserted at the edge of the CN. 

- The OoBTC signalling procedures shall be supported by the call control protocol on the Nc interface, for 
example codec negotiation, codec modification, codec list modification, codec renegotiation, and codec list re- 
negotiation. BICC CS2 (see 3GPP TS 29.205 [6]) supports such a mechanism, through the APM procedures 
defined by [7]. 

If TMR = 3. IKhz Audio is set for incoming calls, this shall be kept if OoBTC is intiated at the edge of the 
PLMN. 

For mobile originating calls, TMR=speech shall be used for speech calls with OoBTC. For other TMR values 
OoBTC shall not be used. 

- The OoBTC signalling procedures shall be supported by the bearer control protocol on the lu and Nb interfaces, 
for example to increase the bandwidth of the bearer (if needed) in the procedures for the codec modification. 

4.2 Relationship between OoBTC and In-band TFO 

OoBTC is used before call set-up to attempt to establish an UE-UE transcoder free connection. If successful the result is 
a saving of transcoding equipment in the path and provides a cost efficient transmission. 
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The In-band TFO protocol (described in [10]) is activated after call set-up only if transcoders are inserted in the path. In 
case two transcoders in tandem (a pair of transcoders with PCM coding between them) are able to communicate to each 
other (both support TFO), then the inband TFO protocol allows the transcoders to compare coding schemes. If 
compatible codec types exist, the transcoders are able to overwrite the PCM coding with the pure compressed speech 
(effectively bypassing the_transcoding functions). In-band TFO provides fast fallback mechanisms in case the TFO 
connection can not be maintained (insertion of CCD, DTMF, tones, etc). In-band TFO provides no direct saving of 
transmission costs. 

If the OoBTC fails to establish the TrFO and transcoders are required, then in-band TFO may be used after call set-up. 
Inband TFO shall be the fallback mechanism when transcoders cannot be avoided, either at set-up or during the 
conmiunication phase. In-band TFO shall be used for interworking with the 2G systems (e.g. GSM) using PCM coding. 



4.3 Lawful interception 



The TrFO shall be maintained if the interception is made due to the lawful interception. Two decoders are needed to 
monitor the TrFO call. 

Lawful interception shall not have any influence on the establishment or maintenance of the TrFO connection in order 
to avoid any audible effect in speech quality or noticeable effect in speech delay to the end users. 

The existing requirements for lawful interception shall be considered, these are described in [9] . 



5 General Principles 

5.1 Network Model 

The codec negotiation mechanism (OoBTC) is designed to work in the general situation where more than two call 
control (CC) nodes need to participate in the codec negotiation. The codec negotiation mechanism works as follows: 

- Originating CC node: sends its list of supported codec types and options, listed in order of preference. 

- Transit CC nodes: if needed, analyse the received list of options, delete unsupported options from the list and 
forward the list. No modification is done to the preference levels of any of the listed codecs. 

- Terminating CC node: analyse the received list of options with their associated priorities and selects the 
supported option with highest indicated priority appropriate for the call. 

Figure 5.1/1 illustrates the architecture for Rel-4 for UMTS to UMTS TrFO connection. The transit network may exist 
for calls between PLMNs or between islands of mobile CNs separated by transit networks. This figure is a basic 
illustration, OoBTC shall apply to other access technologies where the OoBTC procedures are supported, i.e. not 
limited to this figure. The negotiation occurs at call set-up phase, and possibly later on in the call due to other changes 
such as handover or relocation. However, as described in the next clause, it shall be possible to modify the selected 
codec at any moment during the active phase of the call. 

Further detail of the Call & Bearer Separation for 3GPP is described in [8]. 
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OoB Codec 
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Figure 5.1/1. Basic Architecture for UMTS to UMTS TrFO Connection 

The following clauses describe successful call establishment scenarios using the codec negotiation mechanism. 



5.2 Simple call set-up 



The signalling flow for the simple call set-up case is illustrated in figure 5.2/1. Codec negotiation is done prior to the 
establishment of bearer connections, so that appropriate bearer resources are committed to the call. In the proposed 
sequence, the codec negotiation starts with the lAM message containing the list of supported codec types (in this 
example v, w, x, y, z), sent by the Originating MSC (0-MSC). Transit nodes may puncture out (i.e. delete) codec types 
from the list (in this example y). The terminating MSC (T-MSC) selects the codec type (here v) The selected codec is 
conveyed in an APM message, together with the remaining list of alternative, but currently not selected codec types 
(here v, x, z). 
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Figure 5.2/1. Basic Codec Negotiation Sequence 
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The codec list for BICC is specified according to [7], where each 3GPP codec entry is defined according to [5]. 

5.3 Media Gateway Control for Codec Handling 

The general handling of MGW control procedures are detailed in [8]. Specific handling related to the control of the 
speech encoding is detailed in Figure. 5.3/1. The terms context, termination, streams and stream properties are described 
in the ITU-T H.248 "Media Gateway Control Protocol" [13]. 



Stream property: 
Speech codec = codec x 



streams 



Media Gateway 



context 



Stream property: 
Speech codec = codec y 
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Figure 5.3/1. MGW control for speech codec 

The handling of transcoding between one codec type (media stream property applied at one termination) and another 
codec type (media stream property at other termination) is a function of the MGW. The media stream property for 
Audio Codec Type is defined in Annex C of the ITU-T MGW control protocol, H.248. 

If TFO-incompatible codec types are applied at different terminations of the same context, the MGW shall insert a 
transcoder. For the definition of TFO-compatibility between 3 GPP codec types and codec configurations see [10], 
clauses 11 and 12. 

Between codecs of the AMR codec family, the MGW need not insert a transcoder, if the codec types are TFO- 
compatible according to [10], table 11-1, and 

- the codecs use the same ACS; or 

- the ACSs are TFO-compatible and the use of codec modes is restricted to a common subset of the ACSs by 
means of maximum rate control. In this case the MGW shall coordinate the rate control request. 

Between codecs of the AMR-WB codec family, the MGW need not insert a transcoder, if 

- the codecs use the same ACS; or 

- the use of codec modes is restricted to a common subset of the ACSs by means of maximum rate control. In this 
case the MGW shall coordinate the rate control request. 

5.4 UP Framing Protocol Handling for TrFO 
5.4.1 Framing Protocol Initialisation 

For TrFO calls the compressed speech is carried end to end (RNC to RNC or between RNC and other compressed voice 
terminal). In 3 GPP Core Networks compressed voice framing protocol shall be specified by the Nb User Plane 
specification. The specification for lu interface is defined in [4], the specification for the Nb interface is defined in [12]. 
The framing protocol for these interfaces is the same, lu framing and is thus described as such, for both the lu interface 
and the Nb interface. For compressed voice only the support mode is used, thus for TrFO the UP Initialisation 
procedure defined for the Nb UP shall be supported by the CN, when a CN MGW is required to establish a connection. 
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When negotiating TrFO OoB, a given serving MSC server shall consider the capabilities of the RNCs and MGWs, 
which are candidates to handle the TrFO call and which are controlled by this MSC server via an lu/Mc interface. For 
TrFO, the selected RNC and MGW have to be able to support at least one lu/Nb UP version with TrFO capabilities. 
Each MGW and RNC that supports TrFO shall support lu/Nb UP version 2. If an RNC only supports lu UP version 1 
without TrFO capabilities, the MSC server shall insert a transcoder at the MGW that is connected to this RNC. For a 
TrFO call, each MSC server shall indicate in the "RAB assignment"/" Add request" only UP versions with TrFO 
capabilities. In the inband UP framing protocol version negotiation during framing protocol initialisation, the informed 
RNCs/MGW shall only offer and/or accept UP version listed in the "RAB assignment"/" Add request". 

The lu framing Protocol is established through the CN in a forward direction, independently of the bearer establishment 
direction. The Notify message to indicate bearer establishment shall not be sent until the lu framing has been initialised. 
The continuity message (COT) shall not be sent forward until the Notify message has been received from the MGW and 
also the COT from the previous server has been received. The sequences for mobile originated calls are shown in 
figures 5.4/1 and 5.4/2 for forward bearer and backward bearer establishment, respectively. The parameters in the Add 
Request messages in the Figures are described in further detail in clause 5.4.5. 
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Figure 5.4.1/1: lu Framing Protocol Establishment, Forward Bearer 
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Figure 5.4.1/2: lu Framing Protocol Establishment, backward bearer. 

The transport independent call control procedures in [8] shall support a continuity mechanism, as described above. 

5.4.2 RFCI Storage 

The RNC shall allocate RAB Subflow Combination Indicators to the SDU formats (SDU formats sent to the RNC by 
the MSC in the RAB Assignment). This allocation is then sent in the lu Framing Initialisation PDU by the RNC in the 
User Plane. For further details see [3] and [4]. 

During the TrFO call establishment each MGW linked into the call shall store the RFCIs received from lu Framing 
PDU Type 14. The first subflow combination in the initialisation frame corresponds to an Initial Rate Control, i.e. 
indicates the highest rate for the first speech mode to be used in the direction of the Initialisation Acknowledgement 
frame. 

After the out of band codec negotiation has been performed, if the originating side is a UTRAN, then on request from 
the MSC for a RAB Assignment, it shall initiate the lu user plane. If the originating side is a network that does not 
support lu Framing then the lu Framing initialisation is initiated by the GMSC, as described in detail in Clause 6.7. An 
Initialisation Protocol Data Unit (PDU) shall be sent to the first MGW in the call connection. Each initialisation leg is 
acknowledged per TrFO Link, i.e. per MGW-MGW interface. The subsequent initialisation is performed using the same 
RFCI set as received from the preceding node, independently of the Stream mode directions (i.e. if the terminations are 
not through connected). 

This is shown figure 5.4.2/1. 

Figure 5.4.2/1: RFCI Storage and subsequent initialisation in MGW 

When the MGW terminations are through-connected and the RFCIs at both terminations are matching, then the MGW 
may revert to transparent mode; the RNCs shall not perform any subsequent lu Framing initialisations without explicit 
request by the serving MSCs. 
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All succeeding MGWs in the path shall behave in a similar way as described above. 

5.4.3 RFCI Value Correction 

At the terminating end of a TrFO connection with lu Framing initialised to the terminating MGW, the originating RFCI 
allocation is stored. The terminating RNC is then requested to perform a RAB Assignment towards the terminating 
MGW. This results in an lu Framing initialisation, where the allocation of the RFCI values is independent from the 
Originating RNCs allocation. These values may then be different to the originating RNCs set. 

The terminating MGW shall acknowledge the lu Framing Initialisation and compare the RFCI values stored from the 
originating side. If the allocated index values do not match, then the MGW shall perform one of the following 
procedures: 

1) initiate an lu Framing Initialisation PDU towards the terminating RNC with the RFCI allocation as defined 
by the preceding node (previously stored in the MGW. This behavior is shown in figure 5.4.3/1 and termed 
'RFCI value correction') As the first Subflow combination received from the terminating RNC corresponds to 
an initial (maximum) rate control the MGW shall send a Rate Control PDUindicating this maximum speech 
mode back to the preceeding node in the core-network. 

2) map the RFCI indices of the incoming side to the corresponding RFCI indices at the outgoing side for all 
SDUs passed between the lu Framing protocol terminations. As the first Subflow combination in the luUP 
initialisation corresponds to an initial rate control, i.e. indicates maximum rate for the mode to be used (in 
direction of Initialisation acknowledgement frame) it is treated as the initial maximum rate control (see [4]) 
the MGW shall initiate a Rate Control PDU indicating this maximum speech mode toward the terminating 
RNC. Similarly as the first Subflow combination received from the terminating RNC corresponds to an initial 
(maximum) rate control the MGW shall send a Rate Control PDUindicating this maximum speech mode 
back to the preceding node in the core-network. For further details on the rate control see clause 5.7. 





MGw Termination 




RFCIs Stored 











MGw 




Figure 5.4.3/1 :RFCI Value Correction 

Further details of the TrFO call establishment are described in clause 6. 

This resolution handling is required also during RNC relocation; further details are described in clause 6. 

5.4.4 TrFO Break 

The event and procedure when a TrFO connection must be interrupted at a certain point in the path, e.g. due to a 
supplementary service invocation or for handover/relocation, is termed "TrFO Break". A TrFO Break may occur at a 
MGW as a consequence of a command directed by the associated Server. During this period the lu User Plane protocol 
is terminated by this MGW, in general at both sides of the MGW. This means that it must respond to new Initialisation 
PDUs and Inband Rate Control PDUs. The MGW inserts a TrFO Break Function, which then makes use of the stored 
RFCI values, in order to perform the required lu Framing protocol functions and interpret the payload. Further call 
scenarios for specific services that incur a TrFO break are described in clause 6.. 

5.4.5 TrFO Break Recovery 

During the TrFO break situation the individual connections are free to change, the RFCIs may have changed and also 
the rate control (maximum rate, current rate). After the service that caused the TrFO break is complete, the MGW shall 
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check if TrFO.can be re-established. If the coding schemes are matching but the RFCI's have changed then RFCI value 
correction can be performed at the RNC side. In order to correct any changes in rate control between two RNCs, the 
MGW shall send a rate control request from each Termination, with the current rate and maximum rate applied at the 
other Termination. This will then result in the Distributed Rate Decision between the two RNCs in the call. 

5.4.6 MGW Control Protocol lu Framing Package properties 

The following is a summary of the lu Framing H.248 requirements; the procedures are described in [12] and are valid 
for lu Framing in Support Mode: 



Additional Package Properties: 

lu Framing Termination Type: Values 

lu Framing Initialisation Procedure: 



lu-RAN (lu Framing Protocol on lu Interface) 

lu-CN (lu Framing Protocol on Nb Interface) 

Values - Incoming (For lu-CN: the lu Framing Protocol initialisation is 
received by the media gateway and used for subsequent initialisation from this 
MGW. For lu-RAN this indicates the originating RNC interface). 

- Outgoing (For lu-CN the lu Framing Protocol is generated by the core 
network MGW, i.e. initialised on the Nb Interface. For the lu-RAN interface 
this specifies the terminating RNC Interface) 



5.5 TrFO/TFO Codec Negotiation Harmonisation 

When OoBTC procedures are initiated to a node where compressed voice cannot be supported (either at the node or to 
the preceding node) then a transcoder is inserted. This can be due to the transport technology (e.g. TDM) or due to the 
access technology (e.g. GSM with TDM based A-interface). The OoBTC procedures can result in the following call 
scenarios: 
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Figure 5.5/1 : Cascaded TrFO & Transcoding 

In Figure 5.5/ 1 the OoBTC cannot proceed as the call crosses a transit network that does not support compressed voice. 
The same could occur if the transit network did not support out of band codec negotiation (Support in BICC is 
optional). 

In Figure 5.5/2 the OoBTC procedures result in the call terminating to a TDM based GSM access. As the GSM radio 
access transcodes to default PCM codec, the OoBTC results in default PCM selected. The reply is passed back to the 
originating network, which then inserts a transcoder from default PCM to AMR for the UMTS radio access. 
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Figure 5.5/2: UMTS to GSM interworking 

In a similar situation to that described in Figure 5.5/2, it is also possible that the OoBTC procedures result in 
UMTS_AMR_2 as the selected codec, as this is compatible with FR_AMR codec. This is the optimal codec selection 
for speech quality purposes. In this case, the transcoder shall be inserted at the terminating MGW in order to transcode 
between PCM and UMTS_AMR_2, and UMTS_AMR_2 shall be signalled back to the originating UE. TFO can then 
be used on the terminating A-interface to allow FR_AMR to be passed between the tandemed codecs, allowing the best 
speech quality in the core network. 

Further to the scenario described above in Figure 5.5/2, where there is no TFO compatible codec between the UMTS 
UE and the GSM MS it is also possible that the OoBTC procedures result in UMTS_AMR as the selected codec. In this 
case, the transcoder shall be inserted at the terminating MGW in order to transcode between PCM and UMTS_AMR (as 
an example), and UMTS_AMR shall be signalled back to the originating UE. Bandwidth savings and avoiding 
degradation in speech quality are then achieved in the core network. 

For TFO to establish between the transcoders in the above scenarios, each TRAU must send a codec list inband after the 
call has been established. If a common codec type is available (determined by pre-defined rules, described in TFO 
specification [10]) then the OoBTC procedures need to be informed so that a codec modification can be performed. This 
is shown in Figure 5.5/3. Note - a modification could also be required when a common codec type has been selected but 
the ACS is not common. 
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Figure 5.5/3: TFO support by OoBTC signalling 

In H.248, the vertical MG control protocol, the coding types are specified by Media Stream Property, as defined by 
Annex C of H.248 specification. A specific package is used for TFO (see [12]). 



ETS\ 



3GPP TS 23.153 version 9.1.0 Release 9 21 ETSI TS 123 153 V9.1.0 (2011-01) 

The basic requirements are listed below: 

i) Property for TFO Codec List (same format as for [5]) 

ii) Event for Optimal Codec, as determined by TFO in-band protocol 

iii) Event for Distant Codec List sent by the distant TFO partner 

iv) Event for TFO status 

v) Procedures to define and enable TFO 

The TFO package allows the Server to request the MGW to initiate the TFO in-band protocol towards a far end 
transcoder. The package includes a property to turn on/off the TFO (tfoenable); this may be required prior to TrFO 
break situations such as handover. 

The TFO Codec List (H.248) is passed via the Mc interface from the Server to the MGW. The first entry of the TFO 
Codec List (H.248) shall be used by the MGW as the 'Local Used Codec'. The other entries of the TFO Codec List 
(H.248) shall be used by the MGW as Local Codec List in the TFO in-band negotiation (see [10]). For adaptive multi- 
rate codecs (AMR and AMR-WB codecs) some control of the level of negotiation is performed by the "Optimization 
Mode" parameter in the respective Single Codec information element in the TFO Codec List (H.248) (see [5] and [12]). 
This allows a node to indicate if the offered ACS may be modified or not during TFO procedures, and this is mapped to 
the appropriate parameter in the TFO protocol by the MGW. If for a Single Codec information element in the TFO 
Package from the Server to the MGW the OM is set to "Optimization of the ACS not supported", then the TFO 
Negotiation shall not change the offered ACS of the respective Single Codec information element. 

The MGW returns Notification Events for the Distant Codec List sent by the far end and the Optimal Codec Type as 
selected by the Codec Selection mechanism in TFO. The first entry of the Distant Codec List (H.248) is the 'Distant 
Used Codec' as received by the MGW during TFO in-band negotiations. The other entries of the Distant Codec List 
(H.248) are the entries of the Distant Codec List as received by the MGW from the distant TFO Partner (see [10]). The 
Server then compares the Distant Codec List (H.248) with its previously negotiated Available Codec List (BICC). If the 
lists are not the same then an OoBTCCodec List Modification or Mid-call Codec Negotiation may be performed. If for 
a Single Codec information element in the TFO Package from the MGW to the Server the OM is set to "Optimization of 
the ACS not supported", then the offered ACS of the respective Single Codec information element shall not be changed 
during OoBTC procedures. 

If the TFO Status event is supported by the MGW and has been configured by the MSC Server, the MGW shall return 
notification indicating whether a TFO link has been established or broken. The MGW should not report transient TFO 
status change. 

5.6 CN Node handling of Codec Types & Codec Modes 
5.6.1 Signalling between UE and MSC 

The default Codec Type for 'R99 UMTS only' terminals is UMTS_AMR, the default Codec Type for all terminals 
supporting GSM and UMTS radio access is UMTS_AMR_2, (see [5] for the detailed description). The UMTS_AMR_2 
is a superset of the UMTS_AMR. It behaves as a FR_AMR codec in the UL and as a UMTS_AMR codec in the DL. 
This allows all UMTS terminals, except R99 UMTS only terminals, to operate in TFO with GSM terminals. The 
UMTS_AMR_2 is fully compatible with R99 CN nodes (TC in MGW). In any multi-mode configuration the 
UMTS_AMR shall be treated as only TFO and TrFO compatible to itself, not to any other AMR codec Type, to avoid 
incompatibilities in TFO-TrFO-TFO interworking scenarios. In single mode configuration, UMTS_AMR and 
UMTS_AMR_2 are TFO and TrFO compatible, when both codec types use the same single rate ACS, (see [10]). 

During call setup, a UE supporting Rel-4 or later releases will indicate to the MSC the codecs supported by the UE in 
the Supported Codecs List (DTAP) (see [2]). For the codecs in this Supported Codecs List (DTAP), no order of priority 
is defined. 

If no Supported Codecs List (DTAP) is received and the UE is 'UMTS only', then the MSC shall assume UMTS_AMR 
as supported Codec Type. If no Supported Codecs List (DTAP) is received, but the UE is 'dual system', then the MSC 
shall assume UMTS_AMR_2 as the supported codec type. The MSC shall assume 'dual system' support only if the UE 
indicates at least one GSM speech version in Octet 3a etc. of the Bearer Capability. 
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5.6.2 Node originating the OoBTC codec negotiation 

The node originating the OoBTC codec negotiation shall implement the procedures described in Q. 1902.4, subclause 
8.3.1 [6]. Additionally, the following applies: 

In UTRAN, GERAN lu mode or GERAN AoIP mode, when constructing the list of codecs (and configurations for 
AMR or AMR-WB codecs) for the Supported Codecs List (BICC), the MSC Server should take the codec types and 
codec configurations supported by the RNC or BSC into account (see subclause 5.6.6 for UTRAN or GERAN lu mode 
and section 5.6.7 for GERAN AoIP mode). The MSC may include more than one Single codec element indicating the 
same codec type, but different configurations, in the Supported Codecs List (BICC) (see [5]). 

NOTE: This may be necessary, e.g. if the RNC supports for an AMR codec different sets of codec modes, e.g., (a, 
b, c, d) and (e, f, g), which are not subsets of each other, and the RNC does not support combinations of 
these sets, e.g. (a, b, c, d, e, f, g). 

For AMR codecs the originating CN node shall use the "Optimization Mode" parameter in the Single Codec 
information element in the Supported Codec List (BICC) (see [5]) to indicate whether or not other nodes may change 
the offered ACS. 

EXAMPLE: An RNC implementing only the prioritised RABs for interoperability testing specified in [18] will 
support for the UMTS_AMR_2 codec e.g. the set of codec modes (12.2, 7.4, 5.9, 4.75), but none 
of its subsets containing 2 or 3 codec modes. If the MSC Server connected to this RNC includes 
the codec configuration (12.2, 7.4, 5.9, 4.75) in the Supported Codecs List (BICC), it will 
therefore set the OM parameter of the respective Single Codec information element to 
"Optimization of the ACS not supported". 

For AMR codecs, if the OM is set to "Optimization of the ACS supported", the originating CN node shall indicate the 
maximum number of codec modes (MACS) that may be selected for the ACS during speech codec negotiation. This 
maximum number of codec modes may depend on optimization strategies applied by the originating CN node. The 
recommended value is 4 (see [10]). 

For AMR-WB codecs the "Optimization Mode" is defined implicitly by the configuration parameter "Config-WB- 
Codec" in the Single Codec information element (see [5]). If for a configuration the OM is set to "Optimization of the 
ACS supported", then the configuration may be changed to any other allowed configuration specified in [5]. 

In order to support interworking with 2G systems it is recommended that MGWs support 2G codecs (GSM_HR, 
GSM_FR, GSM_EFR, PDC_EFR, TDMA_EFR). In order to avoid modifications during handover between 2G and 3G 
systems the MSC nodes may give preference to a suitable 2G codec. 

Whenever one or several TrFO links have been already established and initialised, the CN node (e.g. the serving CN in 
case of Call Hold scenarios, the visited CN node in case of Call Forwarding scenarios, etc.) initiating a subsequent 
codec negotiation on a new call leg or a mid-call codec negotiation on an established and initialised TrFO link, should 
give the already negotiated Selected Codec (BICC), including its ACS, highest preference to reduce the probability of 
having to perform a bearer re-establishment or UP re-initialisation of the already established and initialised TrFO links. 

The creation of a "structured" Supported codec list shall be as described for SIP-I (see Clause 9.7.2). 

NOTE: The auxiliary pay load types do not apply to BICC. 

5.6.3 Intermediate node 

An intermediate node taking part in an OoBTC codec negotiation shall implement the procedures described in 
Q. 1902.4, subclause 8.3.2 [6]. Additionally, the following applies: 

If a Single Codec information element for an AMR codec is included in the Supported Codecs List (BICC), with the 
OM set to "Optimization of the ACS not supported", the intermediate node shall delete the Single Codec information 
element 

i) if the codec type is not supported; or 

ii) if one or more codec modes of the offered ACS are not supported. 
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If a Single Codec information element for an AMR codec is included in the Supported Codecs List (BICC), with the 
OM set to "Optimization of the ACS supported", the intermediate node 

i) shall delete the Single Codec information element, if the codec type is not supported; 

ii) shall delete codec modes from the offered SCS and ACS, if they are not supported. If the last codec mode is 
deleted from the offered SCS, the Single Codec information element shall be deleted from the Supported Codecs 
List (BICC); 

iii) shall reduce MACS to a locally supported value, if necessary; 

iv) may change the ACS to a different ACS within the offered SCS; and 

v) shall change the OM parameter from "Optimization of the ACS supported" to "not supported", if necessary. 

NOTE: In interworking scenarios with TFO, step (iv) may prevent the establishment of an end-to-end tandem free 
and transcoder free connection; therefore, the intermediate node should not do this without a good reason. 

During the processing of a Single Codec information element of an AMR codec with the OM set to "Optimization of 
the ACS supported", the intermediate node may replace the original Single Codec information element by two or more 
new Single Codec information elements, which can be derived from the original Single Codec information element by 
the steps (i) to (v) listed above. 

If a Single Codec information element for an AMR-WB codec is included in the Supported Codecs List (BICC), the 
intermediate node shall 

i) delete the Single Codec information element, if the codec type or codec configuration is not supported; or 

ii) replace a Single Codec information element with configuration 1, 3, or 5 (see [5], table 5.7-1) by a Single Codec 
information element with configuration and, optionally, another Single Codec information element with 
configuration 2 or 4, if configuration 3 or 5 is not supported. 

5.6.4 Node terminating the OoBTC codec negotiation 

The node terminating the OoBTC codec negotiation shall implement the procedures described in Q. 1902.4, subclause 
8.3.3 [6]. Additionally, the following procedures apply: 

The terminating node shall process the Supported Codecs List (BICC) as described for the intermediate note in 
subclause 5.6.3. 

In UTRAN, GERAN lu mode or GERAN AoIP mode, when processing the codec types (and configurations for AMR 
or AMR-WB codecs) in the Supported Codecs List (BICC), the terminating MSC Server should take the codec types 
and codec configurations supported by the terminating RNC or BSC into account (see subclause 5.6.6 for UTRAN or 
GERAN lu mode and section 5.6.7 for GERAN AoIP mode). 

For the selection of the Selected Codec (BICC) from the Supported Codecs List (BICC), the following additional 
procedures apply: 

If an adaptive multi-rate codec is selected, then the decision about the actual codec modes to be included in the selected 
ACS shall also be made by the terminating CN node. If the OM of the offered configuration is set to "Optimization of 
the ACS supported", the selected ACS may be different from the offered ACS, but it shall be a subset of the offered 
SCS and be consistent with MACS. 

In order to provide harmonisation of out of band codec negotiation (for TrFO) and inband codec negotiation (for TFO) 
similar codec type and codec configuration selection mechanisms as those being defined for TFO should be applied for 
TrFO (see [10]). 

NOTE: For TrFO codec negotiation, besides the speech quality additional aspects may be considered which are 
not applicable to TFO, e.g. the location of the transcoder that may need to be inserted or possible 
bandwidth savings in the core network. 

If an adaptive multi-rate codec is selected, the terminating MSC Server shall exactly specify the ACS in the Selected 
Codec (BICC) and set the OM to "Optimization of the ACS not supported". 



ETSI 



3GPP TS 23.153 version 9.1.0 Release 9 24 ETSI TS 123 153 V9.1.0 (2011-01) 

In the Available Codecs List (BICC), sent back to the originating node, the terminating MSC server may include more 
than one Single Codec information element indicating the same codec type, but different configurations. Single Codec 
information elements for adaptive multi-rate codecs may also be included with the OM set to "Optimization of the ACS 
supported" and the ACS being a subset of the SCS. 

According to Q. 1902.4, subclause 8.3.3 [6], the terminating node shall include the Selected Codec (BICC) in the 
Available Codecs List (BICC). For AMR and AMR-WB codecs, the following appHes: 

If the Selected Codec (BICC) is an AMR codec, it shall be considered as included in the Available Codecs List (BICC), 
if the Available Codecs List (BICC) contains a Single Codec information element with the same codec type and 

- exactly the same configuration, i.e. the same ACS and the OM set to "Optimization of the ACS not supported"; 
or 

- the Selected Codec (BICC) is consistent with the Single Codec information element, i.e. the selected ACS is a 
subset of the SCS of the Single Codec information element, the Number of codec modes in the selected ACS is 
less or equal to the MACS parameter of the Single Codec information element, and the OM of the Single Codec 
information element is set to "Optimization of the ACS supported". 

If the Selected Codec (BICC) is an AMR-WB codec, it shall be considered as included in the Available Codecs List 
(BICC), if the Available Codecs List (BICC) contains a Single Codec information element with the same codec type 
and 

- exactly the same configuration, i.e. the same the configuration parameter "Config-WB -Codec"; or 

- any configuration for which the OM is set to "Optimization of the ACS supported". 

The creation of a "structured" Available codec list shall be as described for SIP-I (see Clause 9.7.3). 
NOTE: The auxiliary pay load types do not apply to BICC. 

5.6.5 Signalling between server and MGW 

According to Q. 1902.4, subclause 8.3 [6], during the OoBTC codec negotiation a server can provide its associated 
MGW with the preferred codec from the Supported Codecs List (BICC), and as a result of the negotiation the server 
will provide its associated MGW with the Selected Codec (BICC). The information is sent via the Mc interface as 
Codec (H.248). 

If the Codec (H.248) is an adaptive multi-rate codec, the server shall exactly specify the ACS in the respective Single 
Codec information element and set the OM to "Optimization of the ACS not supported", both for the preferred codec 
and the Selected Codec (BICC). 

For the Single Codec information elements of adaptive multi-rate codecs in the TFO Codec List (H.248), the OM may 
be set to "Optimization of the ACS supported", and the ACS may be a subset of the SCS. This applies also to the first 
entry in the TFO Codec List (H.248), the Local Used Codec. 

NOTE: In some scenarios the flexible configuration of the Local Used Codec may be used for a faster TFO 
establishment (see [10]). 

5.6.6 Signalling between MSC and UTRAN or GERAN lu-mode 

The MSC Server shall know the codec types and codec configurations supported by the RNC. The MSC Server shall 
select only from these configurations for the RAB assignment. 

For GERAN lu-mode the MSC Server receives a list of codec types (for definition see [15]) as well as the supported 
codec modes (for an adaptive multi-rate codec type) within the RANAP INITIAL UE MESSAGE, indicating the 
GERAN capabilities, which will be available at the RAB establishment procedure. With this information the MSC 
Server shall delete those codec types and codec modes (for an adaptive multi-rate codec type) from the Supported 
Codecs List (BICC) which are not supported by the GERAN, taking into account the GERAN classmark and the MS 
capabilities. This possibly reduced list shall be used by the MSC Server during the codec negotiation procedure. The 
value of the maximum number of supported codec modes shall be set to 4 (see [10]). 

When the MSC node requests a RAB assignment the Subflow Combinations provided shall either all be initialised by 
the RNC or all rejected with appropriate cause code. 
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The MSC shall always assume "Discontinuous Transmission (DTX)" as mandatory and shall define 'SID' SDUs in 
addition to the negotiated speech codec modes. This is because for TrFO the RAB requested by one RNC must match 
that requested by the peer RNC - they are effectively the same RAB. If one MSC requires DTX support then the RAB 
requested by the far end MSC must also support DTX (even if it is not desired by that MSC). As no Out Of Band 
negotiation for DTX is supported nor DTX control to the UE, DTX shall be mandatory for TrFO connections. 

Once an adaptive multi-rate codec with an ACS has been selected as Selected Codec (BICC), the MSCs shall indicate in 
the RAB Assignment parameters [3] for the Guaranteed Bitrate the lowest speech mode in the ACS (assuming any SID 
frames are smaller than the SDU for lowest speech mode, otherwise the Guaranteed Bitrate shall be set to the largest 
SID frame). The Maximum bitrate shall correspond to the highest mode in the ACS. 

5.6.7 Signalling between IVISC and GERAN AolP-mode 

In both mobile originating and mobile terminating calls the MSC Server receives the Supported Codecs List (BSSMAP) 
- "BSC-SCL" - containing a Hst of Codec types (for definition see 3GPP TS 48.008 [15]) as well as the codec 
configurations (for adaptive multi-rate codec types) within the BSSMAP COMPLETE LAYER 3 INFORMATION 
message, indicating the temporary GERAN capabilities for this call in this cell. 

The Codec Types within this BSC-SCL can be viewed as divided into three different A-Interface types: 

1) Codecs with PCM only on the A-Interface - transcoding always occurs inside the BSS. 

2) Codecs with transcoding inside the BSS, but supported with TFO on the A-Interface. 

3) Codecs supported with "Full IP" for the A-Interface - no transcoding inside the BSS. 

D These are described in detail in 3GPP TS 48.008 [15], subclause 3.2.2.103. 

D These A-Interface types may then be used by the MSC to create a structured "Supported Codec List", with Direct 
Codecs and Indirect Codecs, as described in subclause 9.7.2. 

D When creating the Supported Codecs List (BICC or SIP-I), only codecs supported in GERAN with either "Full IP" 
or TFO shall be included in the "direct" part of the Supported Codecs List (BICC or SIP-I), if also the MS and the 
MGW support them in this way. Codec types and codec configurations not supported in GERAN (with either Full IP or 
TFO) or MS, but supported by the MGW with transcoding, may be negotiated as "indirect" codec types. 

This potentially reduced direct codec list and potentially increased indirect codec list shall be used by the MSC Server 
during the codec negotiation procedure. 

During the Assignment procedure, the MSC server shall include the MSC-Preferred-Codec-List (BSSMAP) as defined 
in 3GPP TS 48.008 [15] sub-clause 3.2.2.103. 

5.7 Inband Rate Control 

Inband rate control shall only allow the RNCs to set the maximum codec mode (maximum bitrate) from the set of codec 
modes that have been negotiated out of band. This procedure is called Maximum Rate Control. The final maximum 
mode selected results from a rate control request from one side and the maximum rate supported at the receiving side; 
the lower rate of these is selected. This is known as Distributed Rate Decision. In TrFO maximum rate control shall be 
supported through the lu Framing protocol and through transit networks supporting compressed voice. The maximum 
rate control procedures are further defined within the lu Framing protocol [4] . 

When the MSC requests for a RAB to be assigned, it shall always define 1 speech mode SDU (lowest rate), and DTX 
SDU as non-rate controllable. Other SDU formats for higher rates shall be defined as rate controllable. The first 
subflow combination in the luUP initialisation shall be treated as an initial maximum rate control. Where a node is in 
TrFO break (e.g. the terminating MGW) this initial maximum rate control received at a given MGW/IuUP termination 
shall be signalled to the other TrFO link using the luUP Rate Control PDU unless the luUP Initialisation frame is to be 
sent on to the next link as in RFCI Value Correction (see clause 5.4.3). 

At SRNS relocation the new RNC shall send a rate control frame at Relocation Detect indicating its current maximum 
rate, it will receive in the acknowledgement the current maximum rate from the far end. This procedure is called 
Immediate Rate Control. Again the distributed rate decision means both RNCs will operate within a common limit. 
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5.8 Modification Procedures 

The OoBTC procedures shall support the following modification mechanisms: 

i) Modification of Selected Codec. 

(The codec type of the Selected Codec (BICC) may be switched to another type within the Available Codecs List 
(BICC), and/or the Active Codec mode Set of the Selected Codec (BICC) may be modified, and/or the 
Supported Codec mode Set of the Selected Codec (BICC) may be reduced.) 

ii) Modification of Available Codecs List 

(The Available Codecs List (BICC) may be reduced by removing codec types and modes) 

iii) Mid-call Codec Negotiation 

(The Available Codec List (BICC) is re-negotiated, allowing the addition and removal of codec types and modes 
compared to the previous Available Codec List (BICC), and a new Selected Codec (BICC) is chosen out of the 
new Available Codec List (BICC)) 

The specific call flows when such procedures may be required are detailed in Clause 6. Further information on the 
Available Codecs List (BICC) and the Selected Codec (BICC) is provided in Section 5.2. Further information on codec 
types, codec modes, a Supported Codec mode Set and an Active Codec mode Set is provided in TS 26.103 [5]. The 
basic codec negotiation principles are defined by the BICC Call Control Procedures (see [6]) but the explicit Mc 
interface procedures are added. 
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5.8.1 Modification of Selected Codec 

The codec modification procedures shall support the following changes: 

i) change of the codec type or codec configuration of the current Selected Codec (BICC) to another codec 

type or codec configuration within the Available Codecs List (BICC); 

ii) modification of the Available Codecs List (BICC) according to subclause 5.8.2, (i) to (v), in combination 

with any change of the codec type or codec configuration of the current Selected Codec (BICC) to another 
codec type or codec configuration within the new Available Codecs List (BICC). The modification of the 
Available Codecs List (BICC) may include removal of the current Selected Codec (BICC) from the list. 

The procedures described in Q. 1902.4, clauses 10.4.1 to 10.4.3 [6] shall apply. 

The new codec type and codec configuration may be selected freely from the Available Codecs List (BICC). For an 
AMR codec or AMR-WB codec, a codec configuration may be selected if it is considered to be included in the 
Available Codecs List (BICC) according to the criteria specified at the end of subclause 5.6.4. 

For the coding of the new Selected Codec (BICC), the new Available Codecs List (BICC), and the new Codec (H.248), 
the same rules apply as specified in subclauses 5.6.4 and 5.6.5. 

In Figure 5.8.1/1 and 5.8.1/2 the basic codec modification procedure is shown. This Figure is an example; the codec 
modification procedure may be initiated by any node within the call. 

Upon Reception of a Modify Codec message (action 5 and 9 in Figure 5.8.1/1), a server node shall check if the Selected 
Codec is altered according to the criteria above. If the Selected Codec is not altered, the procedures in Section 5.8.2 
(Modification of the Available Codec List) apply, otherwise the server node shall send a 'Reserve Characteristics' 
procedure to the attached MGW for the corresponding termination (action 6 and 10 in Figure 5.8.1/1 

To perform a modification of the selected codec at an lu interface, the MSC server shall send a 'Modify Bearer 
Characteristics' procedure to the attached MGW (action 1 and 12 in Figure 5.8.1/1). Upon completion of the 'Modify 
Bearer Characteristics' procedure, the server node shall send a 'RAB Assignment Request' to the radio access network 
(action 2 and 13 in Figure 5.8.1/1). The MSC server shall then wait to receive a corresponding 'RAB Assignment 
Response' message from the radio access network (action 3 and 14 in Figures 5.8.1/2 and 5.8.1/3) before continuing the 
modification procedure. 

An MSC server shall use the 'Reserve Characteristic' procedure for the termination towards the preceeding node (with 
respect to the Modify Codec message) to perform the necessary bearer level modification. The MGW shall respond for 
that termination with the 'Bearer Modified' procedure to indicate that the possible bearer modification to increase 
bandwidth was successful. The MGW shall not wait until the lu UP initialisation is complete before replying with the 
'Bearer Modified' procedure. Each server shall not send forward the modify request to the succeeding node until the 
indication from its MGW that any necessary bearer level modification has been completed (BNC_Modified 
notification). The MSC server shall use the 'Confirm Characteristics' procedure to confirm the modification at that 
termination. 

An MSC server shall use the 'Modify Characteristic' procedure for the termination towards the succeeding node (with 
respect to the Modify Codec message) to confirm the codec modification. 

The specific handling of the lu UP initialisation is described in Section 5.8.4. 

Error Cases are described in Section 5.8.5. 
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Figure 5.8.1/1: Codec Modification Control Procedures 
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Figure 5.8.1/2: Codec Modification acknowledgement 

5.8.2 Modification of Available Codecs List 

The modification of the Available Codecs List (BICC) shall support the following changes: 

i) reduction of the ACS of any Single Codec information element in the Available Codecs List (BICC) for 

which CM is set to "Optimization of the ACS supported"; 

ii) reduction of the SCS of any Single Codec information element in the Available Codecs List (BICC) for 

which OM is set to "Optimization of the ACS supported"; 
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iii) reduction of the MACS of any Single Codec information element in the Available Codecs List (BICC) for 

which OM is set to "Optimization of the ACS supported"; 

iv) change of the OM of any Single Codec information element in the Available Codecs List (BICC) from 

"Optimization of the ACS supported" to "not supported"; and 



V) 



deletion of one or more Single Codec information elements from the Available Codecs List (BICC). 



This shall not include the removal of the Selected Codec (BICC) or of modes from the ACS of the Selected Codec 
(BICC), as this would require a Modification of Selected Codec as described in 5.8.1. 

The procedures described in Q. 1902.4, clauses 10.4.1 to 10.4.3 [6] shall apply. 

For the coding of the new Available Codecs List (BICC), the same rules apply as specified in subclause 5.6.4. 

No modification of the user plane and signalling towards the MGWs and radio access network is required. 

In Figure 5.8.2/1 the basic 'modification of available codec list' procedure is shown. This Figure is an example; the 
codec modification procedure may be initiated by any node within the call. 
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Figure 5.8.2/1 : Modification of Available Codec List 

5.8.3 Mid-call Codec negotiation 

The Selected Codec (BICC) and the Available Codecs List (BICC) can be (re-) negotiated during the call using the 'Mid 
Call Codec Negotiation' mechanism. The Mid-Call Codec Negotiation mechanism results in a new Available Codecs 
List (BICC), where new codec types or modes not within the previous Available Codecs List (BICC) may be included. 
The codec negotiation procedure is performed as for call set-up. 

The procedures described in Q. 1902.4, clauses 10.4.4 to 10.4.6 [6] shall apply. 

The sequence is shown in Figure 5.8.3/1. Starting with the Modify to Selected Codec message, the remaining sequence 
is the same as for the Codec Modification in Section 5.8.1 except that the message name for the modify request is 
'Modify To Selected Codec' (instead of 'Modify Codec') in order to allow collisions between the two procedures to be 
resolved. Everything stated in Section 5.8.1 shall also apply for the Mid-Call Codec Negotiation procedure. 

The node initiating the 'Mid Call Codec Negotiation' mechanism (MSC Server A in Figure 5.8.3/1) shall select a 
Preferred Codec and a Supported Codecs List (BICC), which may contain new codecs and also may not contain codecs 
from the previous Available Codecs List (BICC). If the list no longer contains the previous Selected Codec (BICC), 
then a new codec shall be selected as Preferred Codec. If the previous Selected Codec (BICC) exists within the 
Supported Codecs List (BICC), this codec should be selected as the Preferred Codec. 

If a server node removes the Preferred Codec, from the Supported Codecs List (BICC), the node shall select a new 
Preferred Codec. 
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uccessful Codec Modification 
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Modify Bearer Ack 



MGW-B 
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< 



Confirm 

► 



optionally sent to modify 
codec profile and/or 
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rb 



har 



optionally sent to reduce 
bandwidth when no 
longer required. 



Figure 5.8.3/1 : Mid Call Codec Negotiation 

5.8.4 Detailed Procedures For lu Framing Protocol & Codec Modification 

The luFP must be initialised sequentially from one end to the other in order to store new RFCIs in each node to allow 
TrFO to resume. The luFP shall be initialised in the backward direction with respect to the Codec Modification/Modify 
To Selected Codec message as shown in Figure 5.8.4/1. 
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Server A 



Modify Bearer Char 
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MGW-A 



Server B 



Reserve 



Modify Bearer request 



^eserv 
< 



Modify BearerAck 



^NC_ 
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Modify Bearer request 



Modify BearerAck 



Successful Codec Modification 



MGW-B 
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Modified 
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Modify Codec 



luUP Init [RFCIs] 



luUP Init Ack 



Successful Codec Mod 



Bearer Char 



optionally sent to reduce 
additional bandwidth. 



Figure 5.8.4/1: Successful Codec Modification including luFP 

A MGW receiving a Modify Bearer Characteristics procedure shall be prepared to receive an incoming modify bearer 
procedure, this may be to increase the bandwidth prior to luUP Initialisation or to reduce the bandwidth after the luUP 
Intialisation. The new codec indicated in the Modify Bearer Characteristics procedure shall always result in the MGW 
being prepared to receive an lu UP initialisation for the new codec, even if the SDU format is unchanged. The MSC 
shall send the RAB Parameters IE and NAS Synchronisation Indicator IE to the RNC to indicate that the codec has 
changed and luUP Initialisation shall be generated.. 

Each termination receiving a Reserve_Char will initiate bearer level modification to the preceeding node if needed - i.e. 
if the bandwidth needs to be increased to support the new luUP. No luUP initialisation occurs at this point in time. If 
the Codec Modification Request is terminated by a MGW the luUP init through the core-network is triggered by the 
setting of the 3 GUP package property 'initialisation direction' to 'OUT' in either the Reserve_Char or the Confirm_Char 
procedure; the MGW shall then start the luUP Initialisation out from that Termination. If the node terminating the 
modification is an RNC then it will generate a new luUP Initialisation toward its access MGW, each Termination shall 
have the initialisation direction set to 'IN'. Each MGW shall in turn acknowledge the luUP Init to the succeeding node 
(with respect to the modification request) and forward the RFCIs in an luUP Initialisation to the preceding MGW (as for 
call set-up). After completing the lu UP initialisation and receiving the'Confirm Characteristics' procedure, the MGW 
may decrease the bandwidth of the corresponding bearer performing the 'Modify Bearer' procedure (if needed) - no 
bearer bandwidth reduction shall be initiated while the UP is still initialised for the old codec. 

An example call sequence is shown in Figures 5.8.4/2 and 5.8.4/3. 
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Figure 5.8.4/2: Mid Call Codec Negotiation Call Sequence. Call Flow Part 1 
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luFPInit A:k 



Modify Bearer re( luest 



Figure 5.8.4/3: Mid Call Codec Negotiation Call Sequence. Call Flow Part 2 

5.8.5 Unsuccessful Codec Modification 

If the Codec Modification is unsuccessful at a certain node in the connection (due to the MOW rejecting a request to 
reserve the resources or a server rejecting the request to modify the codec) the Confirm_Char message shall be sent to a 
termination that previously performed a successful Reserve_Char Procedure to change the bearer back to its original 
bandwidth (if needed) and free up any reserved resources. However as the luUP has not been modified, the 
Confirm_Char shall not trigger an luFP re-initialisation. The basic sequence is shown in Figure 5.8.5/1 and a detailed 
call flow is described in Figure 5.8.5/2. A server that performed a Modify Bearer Characteristics procedure to a 
termination with the new codec shall perform a subsequent Modify Bearer Characteristics procedure to that termination 
with the old codec in the failure case. As no luFP initialisation occurs in the unsuccessful case the luFP currently 
intialised will then match the old codec restored by the subsequent Modify Bearer Char; the MOW then knows that it 
can return to TrFO. 

The Codec Modification Failure message shall not be returned to a preceding node until notification of the bearer level 
modification (BNC_Modified). 

RAB Assigment Modification Failure 
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If the reason for failed codec modification is due to an unsuccessful RAB Modification Request then the MSC shall 
assume that the old RAB is resumed and thus shall restore the old codec. 



Server A 



Modify Bearer Char 
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3NC Modified 
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Modified 



} 
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Modify To Codec 



Codec Mod Failure 



Char (old Codec) 
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optional 



Figure 5.8.5/1: Unsuccessful Codec Modification 

luUP Initialisation Unsuccessful 

If the luUP initialisation fails (this must be due to some protocol error or transmission error because the resources have 
already been successfully reserved) then the UP protocol is cleared by the peers (see TS 25.415) and therefore the 
MGW shall notify the Server with a Bearer_Released notification, the call shall be cleared (normal MGW initiated call 
clearing applies - see TS 23.205 clause 7.4 [8]). 
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Figure5.8.5/2: Call Sequence for Unsuccessful Modification. Call Flow Part 1 
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Figure5.8.5/2: Call Sequence for Unsuccessful Modification. Call Flow Part 2 



ETSI 



3GPP TS 23.153 version 9.1.0 Release 9 



37 



ETSI TS 1 23 1 53 V9.1 .0 (201 1 -01 ) 



5.9 DTMF Handling For TrFO Connections 

DTMF from the UE is sent via DTAP procedures out-band. For a TrFO call the Originating MSC shall use an out-band 
DTMF procedure, all CN nodes shall support this procedure in their call control protocol. The out-band DTMF 
procedure shall also be used when TrFO is not achieved in order that TFO is possible. Insertion of DTMF in the PCM 
payload can result in the break of the TFO connection. 

For terminating calls DTMF may need to be received by the core network (for voice-prompted services, voicemail 
control procedures etc). If the DTMF is received out-band then out-band procedures shall be maintained in core 
network. 

If the DTMF is received for a TrFO call from an external network inband, in 1.366.2 profile or RTF payload type, then 
the gateway MGW which interworks between lu Framing and the external framing protocol shall report the DTMF 
tones via H.248 procedures to its server. The server shall then use out-band procedures to pass the DTMF through the 
CN. See Figure 5.9/1. 

The same shall apply if a DTMF tone is received for a TrFO call from an external network inband in a PCM coded 
stream. The DTMF tone shall be detected by the MGW and reported via H.248 procedures to its server. In order to 
prevent duplication of DTMF tones due to subsequent PCM legs in the call, when encoding to compressed codecs the 
detected tones shall not be allowed to continue in the compressed stream; the DTMF Digits shall be deleted by the 
MGW before entering the speech encoding stage. 

The MGW may also optionally pass DTMF inband where such an option exists for the Nb interface, and is supported by 
the proceeding MGW. 

Transcoding to default PCM to send DTMF tones shall be avoided for TrFO connections. 




Figure 5.9/1 :DTMF received inband from external network 

5.10 Framing Protocol for GERAN AolP mode 

AoIP user plane does not use luFP framing protocol or associated 3 GUP procedures. Rate control procedures are 
performed within RTP. 
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Detailed Call Procedures 



6.1 



Mobile to Mobile TrFO Call Establishment 



MSC Server - T 
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term.T 



1 . interworking 
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(iJcN) 1^ interworking ^! 



T4 

(lu-RAN) 



RNC-0 
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luUP 
term.o M 



optionally removed after call setup j ■ 



optionally removed after call setup 



TrFO Relation between RNC-0 <!=> RNC-T (after call setup) 



I 

starts initialisation of LJ_P j 
► 



Figure 6.1/1 : Configuration during Call Setup of a Mobile to Mobile Call 

Following network and protocol entities are involved in the scenario, outlined in Figure 6.1/1: 

RNC-T, RNC-O: terminating/originating RNCs. 

MSC Server-T, MSC Server-O: MSC Servers, performing service, i.e. codec negotiation. 

MGW-T, MGW-O: terminating/originating MGWs with the optional capability to insert/remove so called. 

TrFO break equipment: (TBEs), i.e. contexts containing an UTRAN- and a CN side ly Framing termination (Tl - 
T4), inter- working in a distinct manner on control level. [Note: context is meant to be the H.248 specific throughout the 
document] . It is aimed to design protocols for TrFO in a way, that these pieces of HW can be removed after call setup 
phase to allow to revert to "simple" AAL2 switching in case of ATM transport. 

lu FP term.T, lu FP term.o: Terminating- and originating- side TrFO peers (ly Framing terminations in RNCs in Figure 
6.1/1). 

RANAP, TICC:C-plane protocol incarnations, responsible for codec negotiation, controlling the respective interfaces 
(lu, Nc), creating, modifying, removing etc. terminations and contexts. 

The final configuration is (at least logically) an end to end TrFO relation between RNC-T and RNC-0 with the option 
to remove the TBEs from the user data path, i.e. to revert to pure AAL2 switching in case of ATM Transport. 
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Figure 6.1/2: Call Setup. Mobile to Mobile Call. Message Flow part 1 
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Figure 6.1/3: Call Setup. Mobile to Mobile Call. Message Flow part 2 
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Figure 6.1/4: Call Setup. Mobile to Mobile Call. Message Flow part 3 

Codec negotiation 

Steps 1. to 6. give the codec negotiation phase. The mobiles inform the network about their capabiHties (1. and 4.). 
Afterwards the MSC-Server performs codec negotiation according to clause 5.6. 

Network side bearer establishment 

MSC-T/MSC-0 shall request seizure of network side bearer terminations with luFP properties (see steps 5. and 7.). 
Intermediate CN nodes that may perform certain service interactions (e.g. IN nodes) have to seize terminations with 
luFP properties as well. 

RAB Assignment 

RAN side terminations with luFP property have to be seized (9. and 17.) before sending RAB Assignment (steps 10. 
and 18.), that contains RAB parameters according to the selected codec and the negotiated ACS. In addition, the 
respective NAS synchronisation indicator shall be included. 



6.2 SRNS Relocation during TrFO 



In order to maintain TrFO connection in SRNS Relocation, procedures specified in 3GPP TS 23.205 [8] and 3GPP TS 
23.009 [11] for "Intra-MSC SRNS Relocation" or "Inter-MSC SRNS Relocation" shall be followed. Note that the 
"Intra-MSC SRNS Relocation" procedure can also be used for relocation between RNCs connected to different 3G 
MSCs (see 3GPP TS 23.009 [11], clause 1, 'Flexible lu interface for handover/relocation' option and 'Intra domain 
connection of RAN nodes to multiple CN nodes' option). 
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6.2.1 Intra-MSC SRNS Relocation 
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-^ vis-a-vis 
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Figure 6.2/1 : Configuration during intra-MSC SRNS Relocation 

Figure 6.1/1 shows the configuration during intra-MSC SRNS relocation. After setting up the new ly interface (towards 
RNC-A') until releasing the old one, the original TrFO relation (A<^B) and the target TrFO relation (A'<^B) exist in 
parallel. Within the respective context (TBE) interworking between Tl, T2 and T3 is necessary: 

T3 will receive initialisation from RNC-A'. 

T2 shall hide initialisation performed on Iu,a' from RNC-B. 

If the option to remove the TBE was applied after call setup, the whole context (TBE) needs to be inserted prior to 
performing SRNS Relocation. Initialisation data need to be available within MGW-A. After Relocation, the context 
(TBE) may be removed again, i.e. the MGW-A again acts as a pure AAL2 switch. 
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Figure 6.2/2: Intra-MSC SRNS Relocation and TrFO. Flow chart part 1 
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Figure 6.2/3: Intra-MSC SRNS Relocation and TrFO. Flow chart part 2 
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Figure 6.2/3: Intra-MSC enhanced SRNS Relocation and TrFO. Flow chart 

RAB Assignment on the new lu leg: 

A RAN side terminations with luFP property (T3) has to be added to the already seized call context (step 2.) before 
sending Relocation Request (4.), that contains all the RAB parameters already applied on the lu leg towards RNC-A. 

UP initialisation 

RNC-A' shall accept the requested set of codec modes and is not allowed to puncture out any negotiated mode. The 
INIT frames shall be according to the RAB parameters received. 
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At reception of an INIT frame from the new RNC, the termination at MGW-A shall not perform forwarding of the luFP 
initialisation. The MGW shall check whether the received RFCI allocations match the stored RFCI allocation. If it does 
not match, it may re-initialise the luFP towards RNC-A' at this point in time. 

Removal of TrFO Break Equipment (TBE) 

If the MGW supports the removal of TBEs, it shall insert the TBE before seizing the additional termination. It may 
again remove the TBE after performing RFCI matching and through-connection of the new termination and the 
termination to the far end party. 

6.2.2 Inter-MSC SRNS Relocation 

The following figures are describing inter-MSC SRNS relocation. The figures are a combination of figure 6.2/1 for 
intra-MSC SRNS relocation and of figures 8.4/1 and 8.4/2 in 3GPP TS 23.205 [8]. 
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Figure 6.2/4: Configuration during inter-MSC SRNS Reiocation 
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Figure 6.2/4 shows the configuration during inter-MSC SRNS relocation. After setting up the new ly interface (towards 
RNC-A') until releasing the old one, the original TrFO relation (A^^B) and the target TrFO relation (A'<^B) exist in 
parallel. Within the respective contexts (TEE) interworking between T4and T5 at MGW-A' and Tl, T2 and T3 at 
MGW-A are necessary: 

T3 (MGW-A) shall perform initiaUsation towards MGW-A'. 

T4 (MGW-A') will receive initiaUsation from RNC-A'. 

T5 (MGW-A') shall hide initialisation performed on Iu,a' from MGW-A and RNC-B. 

If the option to remove the TBE was applied in MGW-A after call setup, the whole context (TEE) needs to be inserted 
prior to performing inter-MSC SRNS Relocation. Initialisation data need to be available within MGW-A. After 
Relocation, the context (TBE) may be removed again. 




Figure 6.2/5: Inter-MSC SRNS Relocation and TrFO. Flow chart part 1 
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Note: There can be interim network transit nodes between IVISC-A and IVISC-A' 

Figure 6.2/6: Inter-MSC SRNS Relocation and TrFO. Flow chart part 2 



ETSI 



3GPP TS 23.153 version 9.1.0 Release 9 50 ETSI TS 123 153 V9.1.0 (2011-01) 



RAB Assignment on the new lu leg: 

A RAN side termination with luFP property (T4 (MSC-A')) has to be seized (step 3.) before sending Relocation 
Request (4.), that contains all the RAB parameters already applied on the lu leg towards RNC-A. 

MAP signalling for handover and codec negotiation 

The MSC-A server shall include an lu-Supported Codecs List and an lu-Currently Used Codec in the MAP Prepare 
Handover request. When selecting the order of priority for the codecs within the lu-Supported Codecs List, MSC-A 
shall take the Available Codecs List (BICC) negotiated with the far end party into account. 

If the MSC-A server supports GERAN AoIP-mode then it may insert an AoIP- Supported Codecs List (Anchor) (MAP) 
in the MAP Prepare Handover Request message to allow MSC-A' to use this information during a subsequent intra- 
MSC handover to GERAN AoIP-mode, see Subclause 6.14.L 

NOTE: the full list of codec types supported by the UE and the anchor MSC for GERAN access is included in 
Radio Resource Information IE in MAP Prepare Handover Request message. 

MSC-A' shall include in the MAP Prepare Handover response the lu-Selected codec and the lu- Available Codecs List, 
i.e. the list of codecs available at the lu interface in MSC-A' after handover. 

Network side bearer establishment and codec handling 

The handling of the bearer establishment between MSC-A and MSC-A' shall be performed as for a normal call with 
OoBTC. For a speech bearer, the MSC-A server shall perform a call set-up with codec negotiation towards the MSC-A' 
server, using a Supported Codec List (BICC) containing: 

a) optionally, the lu-Selected codec (MAP) (negotiated with MSC-A' during the MAP E-interface signalling) if it is 
different from list item b; 

NOTE 1 : This codec can be included as the preferred codec, if MSC-A knows by means of configuration 

information that all nodes of the network support OoBTC, or TrFO/TFO interworking and TFO, including codec 
mismatch resolution. If this codec does not match the Selected Codec (BICC), but is eventually selected for the 
network side bearer to the target MSC (MSC-A'), then either MSC-A must transcode at the anchor MGW or 
MSC-A will need to trigger a codec modification to the far end. Given that the anchor MSC cannot trigger all 
these changes at once, it must first establish the network side bearer - i.e. insert a transcoder at the anchor MGW 
and then trigger the codec modification to the far end as a second step. 

b) the Selected codec (BICC), previously selected for the leg towards the far end party; 

NOTE 2: This codec is preferred, if the anchor MSC-A does not know by means of configuration information if all 
nodes in the network support OoBTC, or TrFO/TFO interworking and TFO, including codec mismatch 
resolution. This is also the best codec to be selected if the goal is to avoid additional transcoding in MSC- 
A or a codec modification from MSC-A towards the far end party. 

c) the default PCM codec; 

d) optionally, further codecs from the lu-Supported Codecs List (MAP) that are applicable to the target radio 
access, e.g. the lu-Selected codec (MAP), if it is not already included according to list item a or b; and 

e) optionally, for subsequent inter-RAT intra MSC-A' handover further codecs from the Available Codec List 
(BICC) that are applicable to other radio access types. 

For UDI/RDI multimedia calls with fallback and service change according to 3GPP TS 23.172 [17], the Supported 
Codecs List (BICC) shall contain the multimedia dummy codec and the Available Codecs List (BICC) can contain this 
codec (see [17], subclause 4.3.7). If the MSC-A server wants to establish a bearer for the multimedia dummy codec, it 
shall include this codec as the preferred codec. 

If MSC-A' receives a Supported Codec List (BICC) with the lAM message, MSC-A' shall select a codec from this Hst, 
taking the lu-Selected codec and the priorities expressed by the order of the codecs in the Supported Codec List (BICC) 
into account. 

- NOTE 3: Usually, selection of the preferred codec of the Supported Codec List (BICC) will result in the best 
speech quality or best transcoder location or both; however, e.g. if MSC-A' knows by means of configuration 
information that OoBTC is not supported on some links in the network, and some nodes in the network are not 
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supporting the creation of a "structured" Supported Codec List (BICC) as specified in subclause 9.7.2, MSC-A' 
can select another codec, e.g. the lu-Selected codec or the default PCM codec. 

If MSC-A' selects the default PCM codec, or if MSC-A' receives an lAM message without a Supported Codec List 
(BICC), MSC-A' shall insert a transcoder in MGW-A'. 

If the Selected Codec (BICC) received by MSC-A in response to the BICC codec negotiation towards the target MSC 
(MSC-A') is different from the current Selected Codec (BICC) used towards the far end, the MSC-A shall insert a 
transcoder in MGW-A. 

MSC-A/MSC-A' shall request seizure of network side bearer terminations with luFP properties (see steps 10. and 12.). 
MSC-A' shall send the Address Complete message only after MGW-A' has indicated the successful initialisation of the 
luFP (step 15.). 

Additionally, when the bearer between MGW-A and MGW-A' was established successfully, MSC-A may initiate a 
codec modification or mid-call codec negotiation as described in Annex A. 

UP initialisation 

RNC-A' shall accept the requested set of codec modes and is not allowed to puncture out any negotiated mode. The 
INIT frames shall be according to the RAB parameters received. 

MSC-A' shall request seizure of network side bearer terminations with luFP properties. 

At reception of an INIT frame from the new RNC, the termination at MGW-A' shall not perform forwarding of the luFP 
initialisation. When the NbFP has been initiahsed from MGW-A towards MGW-A', the MGW-A' shall check whether 
the received RFCI allocations match the stored RFCI allocation. If it does not match, the MGW-A' may re-initialise the 
luFP towards RNC-A' at this point in time. 

Removal of TrFO Break Equipment (TEE) 

If the MGW-A supports the removal of TBEs, it shall insert the TBE before seizing the additional termination. It may 
again remove the TBE after through-connection of the new termination and the termination to the far end party. 

If the MGW-A' supports the removal of TBEs, it may remove the TBE after performing RFCI matching and through- 
connection of the terminations. 

6.2.3 Codec Modification/ Mid-Call Codec Negotiation after Inter-MSC 
Relocation 

6.2.3.1 Codec Modification Initiated by the Far End Side 

Modification of Available Codec List 

If after inter-MSC SRNS relocation the anchor MSC (MSC-S-A) receives a "Modification of Available Codec List" 
procedure from the far end side as described in section 5.8.2, i.e. the Available Codecs List (BICC) is reduced, the 
anchor MSC may terminate the procedure at that point or forward the "Modification of Available Codec List" procedure 
to the serving MSC (MSC-S-A'). I.e. for a modification of the Available Codec List (BICC) without modification of the 
Selected codec, no MAP signalling is used. 

Modification of Selected Codec 

If after inter-MSC SRNS relocation the anchor MSC (MSC-S-A) receives a "Modification of Selected Codec" 
procedure from the far end side as described in section 5.8.1, and both the old and the new Selected Codec (BICC) are 
speech codecs, the anchor MSC may terminate the codec modification procedure, inserting a transcoder if required. 
Alternatively, the anchor MSC may forward the request to modify the codec to the serving MSC (MSC-S-A'), using the 
procedure described below. 

NOTE: The anchor MSC may decide to forward the request to the serving MSC (MSC-S-A'), e.g. when the new 
Selected Codec (BICC) for the call leg between the anchor MSC and the far end side was included in the 
lu- Available Codec List previously received from the serving MSC, and it is possible to (re-)establish 
TrFO end-to-end from the far end side up to the serving MSC. 

If the anchor MSC (MSC-S-A) receives a "Modification of Selected Codec" procedure from the far end side as 
described in section 5.8.1, and either the old or the new Selected Codec (BICC) is the multimedia dummy codec, i.e. the 
far end side requests a service change between speech and multimedia, and the Available Codecs List (BICC) 
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previously negotiated between the anchor MSC and the serving MSC (MSC-S-A') indicates that the service change is 
supported end-to-end, the anchor MSC shall forward the request to modify the radio access bearer to the serving MSC 
(MSC-S-A') and then perform a codec modification procedure for the Nb/Nc interface towards the serving MSC (MSC- 
S-A'). If the service change cannot be performed successfully, the anchor MSC shall reject the request for codec 
modification towards the far end party. 

An example call sequence for the modification of the selected speech codec is shown in figures 6.2/7 and 6.2/8. The 
configuration depicted in figure 6.2/4 applies. 
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Figure 6.2/7: Codec modification after Inter-MSC SRNS Relocation. Flow Chart Part 1. 
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Figure 6.2/8: Codec modification after Inter-MSC SRNS Relocation. Flow Chart Part 2. 



If the anchor MSC (MSC-S-A) wants to forward the modification of the codec used towards the UE and the serving 
MSC (MSC-S-A') from one speech codec to another speech codec within the lu- Available Codecs List, it shall apply 
the following procedure: 

The anchor MSC shall send a MAP Forward Access Signalling request (3) containing the new lu-Selected Codec and 
the corresponding RAB Assign Modify Request message to the serving MSC (MSC-S-A'). 

On reception of the MAP Forward Access Signalling request (3) the serving MSC (MSC-S-A') shall configure the 
attached MGW-A' for the new codec and trigger the "RAB Assign Modify" procedure (5-8) towards the RNC-A'. When 
the serving MSC receives the RAB Assign Modify Response message (8), it shall send a MAP Process Access 
Signalling Request (9) containing the RAB Assign Modify Response and the lu-Selected codec to the anchor MSC 
(MSC-S-A). 

When the anchor MSC (MSC-S-A) receives the MAP Process Access Signalling Request (9), it shall start the codec 
modification procedure (11-19) for the Nb/Nc interface towards the serving MSC (MSC-S-A'), as described in section 
5.8.1. If the anchor MSC needs to change also the Available Codecs List (BICC), it shall additionally initiate a 
procedure as described in section 5.8.2. 

When receiving the "Modify Codec" request (11), the serving MSC (MSC-S-A') shall not reconfigure the RAN and 
shall configure the attached MGW-A' to initate an Nb framing protocol initiation towards MGW-A. 



If the anchor MSC (MSC-S-A) needs to perform a service change from multimedia to speech, it shall send a MAP 
Forward Access Signalling request (3) containing the lu-Supported Codecs List and the corresponding RAB Assign 
Modify Request message to the serving MSC (MSC-S-A'). After successful modification of the RAB, on reception of 
the MAP Process Access Signalling Request (9) the anchor MSC (MSC-S-A) shall start the codec modification 
procedure (11-19) for the Nb/Nc interface towards the serving MSC (MSC-S-A'), as described in section 5.8.1. 



If the anchor MSC (MSC-S-A) needs to perform a service change from speech to multimedia, it shall send a MAP 
Forward Access Signalling request (3) containing the corresponding RAB Assign Modify Request message for a data 
bearer, but no lu-Selected Codec to the serving MSC (MSC-S-A'). After successful modification of the RAB, on 
reception of the MAP Process Access Signalling Request (9) the anchor MSC (MSC-S-A) shall start the codec 
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modification procedure (11-19) for the Nb/Nc interface towards the serving MSC (MSC-S-A'), as described in section 
5.8.1. 



Unsuccessful Codec Modification in the Serving MSC 

After receipt of MAP Forward Access SignalHng request (3), if the modification to the new lu-Selected codec is not 
possible, e.g. because necessary resources are temporarily unavailable in the serving cell or in MGW-A', or the RAN 
does not support the "RAB Assign Modify" procedure, the serving MSC (MSC-S-A') shall keep the old codec and the 
corresponding RAB configuration and shall send a MAP Process Access Signalling request, containing a RAB Assign 
Modify Response ("failed to modify") message, to the anchor MSC (MSC-S-A). If the anchor MSC detects that the 
RAB modification failed, it shall abort the codec modification procedure towards the serving MSC and shall complete 
the codec modification procedure towards the far end side. 



Unsuccessful BICC Codec Modification between Anchor MSC and Serving MSC 

After receipt of a MAP Process Access Signalling Request, containing a RAB Assign Modify Response ("success") 
message, if the subsequent BICC codec modification procedure between anchor MSC and serving MSC fails due to a 
MOW rejecting a request to reserve the resources or a server rejecting the request to modify the codec, the anchor MSC 
shall change the codec used at the lu interface back by sending a MAP Forward Access Signalling request containing 
the previous lu-Selected Codec to the serving MSC (MSC-S-A'). After receipt of the confirmation that the previous 
codec has been restored at the lu interface, the anchor MSC shall complete the codec modification procedure towards 
the far end side. 



6.2.3.2 Mid-Call Codec Negotiation Initiated by the Far End Side 

If after inter-MSC SRNS relocation the anchor MSC receives a "Mid-call Codec Negotiation" procedure from the far 
end side as described in section 5.8.3, and both the old and the new Selected Codec (BICC) are speech codecs, the 
anchor MSC may terminate the mid-call codec negotiation procedure, inserting a transcoder if required. Alternatively, if 
the new Selected Codec (BICC) was included in the last lu- Available Codec List sent by the serving MSC (MSC-S-A') 
the anchor MSC may forward the request to the serving MSC (MSC-S-A'), using the procedure described below. 

If the anchor MSC (MSC-S-A) receives a "Mid-call Codec Negotiation" procedure from the far end side as described in 
section 5.8.3, and either the old or the new Selected Codec (BICC) is the multimedia dummy codec, i.e. the far end side 
requests a service change between speech and multimedia, and the Available Codecs List (BICC) previously negotiated 
between the anchor MSC and the serving MSC (MSC-S-A') indicates that the service change is supported end-to-end, 
the anchor MSC shall forward the request to modify the radio access bearer to the serving MSC (MSC-S-A') and then 
perform a mid-call codec negotiation procedure for the Nb/Nc interface towards the serving MSC (MSC-S-A'). If the 
service change between speech and multimedia cannot be performed successfully, the anchor MSC shall reject the 
request for mid-call codec negotiation towards the far end party. 

An example call sequence for the mid-call codec negotiation of speech codecs is shown in figures 6.2/9 and 6.2/10. The 
configuration depicted in figure 6.2/4 applies. 
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Figure 6.2/9: Mid-call codec negotiation after Inter-MSC SRNS Relocation. Flow Chart Part 1. 
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Figure 6.2/10: Mid-call codec negotation after Inter-MSC SRNS Relocation. Flow Chart Part 2. 



If the anchor MSC (MSC-S-A) wants to forward the (re-)negotiation of the selected codec and the Available Codecs 
List (BICC) towards the UE and the serving MSC (MSC-S-A'), it shall apply the following procedure: 

The anchor MSC shall send a MAP Forward Access Signalling request (2) containing the new lu-Supported Codecs 
List and the corresponding RAB Assign Modify Request to the current serving MSC (MSC-S-A'). When selecting the 
order of priority for the codecs within the new lu-Supported Codecs List, the anchor MSC shall take the new Available 
Codecs List (BICC) negotiated with the far end party into account. 

On reception of the MAP Forward Access Signalling request (2) the serving MSC (MSC-S-A') shall select a codec from 
the lu-Supported Codecs List, configure the attached MGW-A' for the new codec, and trigger the "RAB Assign 
Modify" procedure (4-7) towards the RNC-A'. For details concerning the handling of the RAB Assign Modify Request 
message by MSC-S-A' see 3GPP TS 23.009 [11], subclause 13.4.1. When the serving MSC receives the RAB Assign 
Modify Response message (7), it shall send a MAP Process Access Signalling Request (10) containing the RAB Assign 
Modify Response, the lu-Selected codec, and the lu- Available Codecs List to the anchor MSC (MSC-S-A). 

When the anchor MSC (MSC-S-A) receives the MAP Process Access Signalling Request (8), it shall start the mid-call 
codec negotiation procedure (9-25) for the Nb/Nc interface towards the serving MSC (MSC-S-A'), as described in 
Section 5.8. 

When receiving the "Mid-call codec negotiation" procedure (9), the serving MSC (MSC-S-A') shall not reconfigure the 
RAN and shall configure the attached MGW-A' to wait for an Nb framing protocol initiation from MGW-A. 



Unsuccessful Codec Modification in the Serving MSC 

After receipt of MAP Forward Access Signalling request (3), if the modification to the new lu-Selected codec is not 
possible, e.g. because necessary resources are temporarily unavailable in the serving cell or in MGW-A', or the RAN 
does not support the "RAB Assign Modify" procedure, the serving MSC (MSC-S-A') shall keep the old codec and the 
corresponding RAB configuration and shall send a MAP Process Access Signalling request, containing a RAB Assign 
Modify Response ("failed to modify") message, to the anchor MSC (MSC-S-A). If the anchor MSC detects that the 
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RAB modification failed, it shall abort the mid-call codec negotiation procedure towards the serving MSC and complete 
the mid-call codec negotiation procedure towards the far end side. 

Unsuccessful BICC Mid-call Codec Negotiation between Anchor MSC and Serving MSC 

If after a successful modification of the lu-Selected Codec (MAP) the subsequent BICC codec mid-call codec 
negotiation procedure between anchor MSC and serving MSC fails due to a MOW rejecting a request to reserve the 
resources or a server rejecting the request to (re-)negotiate the codecs, the anchor MSC shall change the codec used at 
the lu interface back by sending a MAP Forward Access Signalling request containing the previous lu-Selected Codec 
to the serving MSC (MSC-S-A'). After receipt of the confirmation that the previous codec has been restored at the lu 
interface, the anchor MSC shall complete the mid-call codec negotiation procedure towards the far end side. 



6.2.3.3 Modification Procedure after Codec Change in the Serving IVISC 

According to 3GPP TS 23.009 [11], subclause 4.4.1, the serving MSC (MSC-S-A') will inform the anchor MSC (MSC- 
S-A) when the lu-Selected codec was changed during a subsequent intra-MSC handover/relocation by sending a MAP 
Process Access Signalling request. If the lu- Available Codecs List was changed during the handover/relocation, the 
serving MSC shall send a MAP Process Access Signalling request including the new lu- Available Codecs List. 

On reception of the MAP Process Access Signalling request the anchor MSC may initiate one of the modification 
procedures as described in sections 5.8.1, 5.8.2, and 5.8.3 towards the serving MSC and/or towards the far end side. I.e. 
towards the serving MSC no MAP signalling is used. Besides, towards the serving MSC (MSC-A') the procedures 
described in sections 5.8.1, 5.8.2, and 5.8.3 are applicable with the modification that the serving MSC shall not modify 
the radio access bearer. 



6.3 IN and Call Forward SS 

In some cases, IN services (e.g. voice prompting) are triggered at CC-IN nodes that require the establishment of an UP 
bearer for tones or announcements to be sent to the calling party. In order to establish this bearer, it is necessary that the 
CC-IN node temporarily selects one codec from the codec list sent from the initiating node, and informs the initiating 
node about the selected codec. Afterwards, the call may continue its establishment to the another node, which may not 
support the selected codec but requests that another one in the list be selected instead. 

A similar situation arises with the CFNRy supplementary service. A UP connection needs to be established between the 
originating and "provisional" terminating CC nodes to enable ringing tones to be sent to the calling party. The type of 
codec must be agreed prior to the establishment of the bearer connection. Afterwards, the call is redirected to another 
node that may not support the selected code but requests the selection of another one. 
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6.3.1 TrFO interworking with SS (VMSC = service interworking node) 



1'^TrFO relation (RNC-O ^ RNC-T)^ 



(or RNC-0 ^ MGW-T in case MGW-T applies a tone/announcment) 



^^ 



Nrnc-o(a)^ 



^NC-T(B)r 




N?NC-T'(Cr 



2"^ (re-negotiated) TrFO relation (RNC-0 <^ RNC-T') 



Figure 6.3.1/1. Codec Modification in case of SS interworking 

In case of supplementary service interworking, it may become necessary to apply codec modification out of band. 
Figure 6.3.1/1 shows the network model, that may apply for a certain set of SS's (call deflection (CD), call forwarding 
on no reply (CFNRy), CF on user determined busy (CFUB), etc.). Common to these scenarios is: 

- the service interworking is controlled by the VMSC (this is common to all SSs). 

- MSC-T extends the call towards MSC-T' according to the f or warded-/deflec ted-to -number. 

An intermediate TrFO relation will in general already exist between two RNC's (RNC-0 and RNC-T in figure 6.3.1/1) 
before the call is diverted to another node, as the ringing tone was applied in backward direction. 

In order to perform codec negotiation with the third node (MSC-T') as well it is necessary to forward the supported 
codec list from MSC-0. MSC-T' signals back the codec it selected and the available codec list. If the codec negotiation 
result is different from the previously performed codec negotiation between MSC-0 and MSC-T, MSC-0 shall be 
informed. MSC-0 shall be able to decide based on the received modified codec type whether lu Framing re- 
initialisation and bearer modification is required. This scenario is depicted in Figure 6.3.1/2 below. If no codec 
modification has to be appHed, MSC-T(B) shall extend the UP initiaUsation towards MSC-T'(C), i.e. MSC-T(B) shall 
initialise a termination (TD) with the property Initialisation Procedure = outgoing. MSC-T' (C) shall also initialise a 
termination TE with the property Initialisation Procedure = incoming. Further call handling follows the mobile to 
mobile call establishment (see clause 6.1). 
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Figure 6.3.1/2: Codec Modification for SS-interworking & UP re-initialisation 
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6.3.2 IN interworking (VMSC ^ service interworking node) 

1'* TrFO relation (RNC-0 <^ MGW-IN) 

M ► 

2"^ TrFO relation (RNC-0 ^ RNC-T) 



1^^ codec negot. 



C —'^— >• • • • 
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3'"^ codec negot. 



♦ ^x / TrFO capable 
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MGW-T(C) 



ISC-T'(D) 




^ CTXef ^ 
MGW-T(D) 



^NC-T(D]r 



Figure 6.3.2/1. Codec Modification in case of IN interworking 

Common to IN interworking scenarios is that service interworking is controlled by an IN service node that is generally 
not the VMSC. 

IN interworking (i.e. in case of a separate IN service node, this is often a Gateway-MSC) may interrupt call 
establishment and apply an intermediate announcement back to the originating side. This means, that codec negotiation 
was in fact performed between the IN service node and the MSC-0. 

When performing further call establishment, it is necessary to proceed with codec negotiation towards MSC-T. The 
codec negotiation process shall consider the capabilities of MGW-IN. 

IN services, similar to call forwarding SS, are possible. The fact that this service interworking is controlled by an IN 
service node, may cause, that the leg towards MSC-T has to be released and a new leg towards MSC-T' will be 
established. Codec negotiation is again necessary from MSC-IN on. 

The sequence chart given in figure 6.3.1/2 applies in principle for the 1^^ and the 2"^ negotiation scenarios with 
following modifications: 

- as MSC-IN may be involved in subsequent service interworking again, the capabilities of MGW-IN shall be 
taken into account during codec negotiation with MSC-T or MSC-T'. This means, that the codec list forwarded 
to the succeeding nodes is in fact the available codec list of the 1^^ negotiation. 

- For the 3^^ negotiation scenario, the leg between MSCin(B) and MSC-T (C) has to be released and a new leg 
toward MSC-T'(D) has to be setup. 
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6.4 Information flow for interaction with Multiparty SS 
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Figure 6.4/1 : Multi-party Call 

The operation of the MGW for conference calls is implementation dependent. The sequence in Figure 6.4/1 shows three 
connections to the MGW, where two were configured TrFO and have matching codecs but the third connection could 
not be made with the same codec type. 

The lu Framing connections for each multi-party call leg shall be terminated in the MGW where the multi-party call is 
controlled. The MGW shall control each connection independently during the multi-party call. 

When the multi-party call is released, if two parties remain in the connection it shall be possible to either revert directly 
to a TrFO connection if both codecs match or OoBTC procedures could be performed to modify one or both of the 
codec types to achieve a TrFO connection. However, if the Server does not perform this then the MGW shall continue 
to resolve the difference in codecs by internal transcoding procedures. 

Codec modification procedures may be employed (see clause 5.8.1) if a common codec exists, this is shown in Figure 
6.4/2, where codec v is common to all parties. 
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6.5 



Figure 6.4/2: Multi-party Caii, with codec modification 

Information flow for handover from UMTS to GSM after 
TrFO establishment 



Inter-system handover procedures are described at call control level in [1 1] and details for bearer independent 
architecture is described in [8]. For TrFO connected UMTS call, when a handover occurs to GSM radio access, by 
definition the A-interface to the ESC shall be default PCM. Prior to receipt of Handover Detect the Anchor MGW has 
one leg (A-interface) stream mode as default PCM and two terminations with compressed voice codec properties. It is 
recommended that after the Handover Complete procedure, the network property is maintained as compressed. Thus the 
Anchor MGW inserts a "TFO Partner" transcoder. Thus no modification to the compressed bearer to 64k PCM is 
required. TFO procedures may then ensure that speech quality is maintained by avoiding transcoding. 

In the Intra-MSC case shown in Figure 6.5/1 the MSC controlling the handover has both codec lists for each radio 
access. The codec negotiation for the UMTS call was performed end to end with UMTS list. If this negotiation resulted 
in a codec being selected that is also included in the GSM list then at handover the MSC shall indicate this codec as the 
current speech version to the ESC and TFO can be achieved. If the selected codec is not supported for the GSM radio 
access but the GSM list contains a codec that is also in the Available Codecs list then the MSC has the option to 
perform codec modification to ensure TFO can be achieved. The MSC may also perform codec list modification by 
sending forward the GSM list to update nodes in the network of the change to the Available Codecs List. 
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TSN 

Selected Codec: AMR, 
^Available L:oaecs:ti^ k.PCM 



^elected Codec: AMR , 



PLMNl 




Available Codecs :EF^,PCM 



PLMN2 




Figure 6.5/1 : UMTS to GSM Inter-System Handover 
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If the Inter-system handover is an inter-MSC handover then the Anchor MSC sends the current speech version and the 
supported speech versions in the Prepare Handover Request message to the MSC-B. If the anchor MSC supports 
GERAN AoIP mode then the Prepare Handover Request message may contain AoIP- Supported Codecs List (Anchor) 
(MAP), see Sub-clause 6.14.1. 

If the current speech version (codec selected for UMTS call) is not included in the GSM list then the MSC-A shall 
indicate a preferred codec in the current speech version parameter. The speech version for the GSM access that is 
finally selected by the MSC-B's BSS, is returned to MSC-A in the Prepare Handover Response message. If the 
following are satisfied: 

- target MSC and ESC support GERAN AoIP mode; 

- AoIP-Supported Codecs List (Anchor) (MAP) was received in MAP Prepare Handover Request; and 

- target MSC supports AoIP codec selection based on received AoIP-Supported Codecs List (Anchor) (MAP), 

then the Prepare Handover Response message shall contain the AoIP-Selected Codec (Target) (MAP) and AoIP- 
Available Codecs List (MAP). 

The MSC-A can then decide if codec modification or codec re-negotiation shall be performed as described for the intra- 
MSC case. For further details on the inter-MSC signalling see section 6.11. The connections are shown in Figure 6.5/2. 
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Figure 6.5/2: Inter-MSC, UMTS to GSM handover, with TDM transport between anchor MSC (MSC-A) 

and target MSC (MSC-B) 
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6.6 



Call Hold/Call Wait 
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Figure 6.6/1 : Configuration during Call Hold/Call Wait scenario 

This scenario assumes subscriber C (served by RNC-O") calls subscriber B (served by RNC-T), currently in 
communication with subscriber A. Subscriber C receives a tone/announcement, applied by terminating side. Then 
subscriber B puts subscriber A on Hold and A receives an announcement (apphed again by terminating side.) 

MGW-0 has to establish an originating side call context (T4, T5), MGW-T the respective terminating one (T3 only, Tl 
from subscriber will be moved to it during the scenario), the B party context has to be inserted into path again (if TBE 
was removed). 



ETSI 



3GPP TS 23.153 version 9.1.0 Release 9 



66 



ETSI TS 1 23 1 53 V9.1 .0 (201 1 -01 ) 




Figure 6.6/2: Call Hold/Call Wait and TrFO. Message flow part 1 
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Figure 6.6/3: Call Hold/Call Wait and TrFO. Message flow part 2 
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Figure 6.6/4: Call Hold/Call Wait and TrFO. Message flow part 3 
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Figure 6.6/5: Call Hold/Call Wait and TrFO. Message flow part 4 
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6.7 



External Network to Mobile TrFO Call Establishment 
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TICC ... a transport independent call control protocol 

(as specified for a 3GPP cs CN) 
any CC ... any external call control protocol 
NNIc ... control plane interface to external network 
NNIt ... transport plane interface to external network 
T1-T4 ... terminations in an H. 248 context 

Figure 6.7/1. Configuration during Call Setup of a External Network to Mobile Call 

The description of Figure 6.1/1 (Configuration during Call Setup of a Mobile to Mobile Call) within clause 6.1 apphes 
for the network and protocol entities involved in the External Network to Mobile Call scenario with following 
modifications: 

No RNC-0 is present - a party served by an external network originates the call instead. 

The originating CN nodes are Gateway nodes (Gateway MSC Server/Gateway MGW). 

The Gateway MGW call context is no TrFO break equipment in general, i.e. Tl in general do not support the luFP 
framing protocol. Appropriate interworking (in some cases transcoding) has to be performed between Tl and T2. 

Therefore Figures 6.1/2 to 6.1/4. (the respective message flows for mobile to mobile call setup) apply in principle as 
well with appropriate modifications outlined below: 

Codec negotiation 

Step 1. Until 6., that give the codec negotiation phase in Figure 6.1/2, shall be applied with following modifications: 

There is no originating UE involved in this negotiation phase 

If the preceding node of the Gateway MSC-Server doesn't support OoBTC procedures for compressed voice types, the 
Gateway MSC-Server shall initiate OoBTC procedures in order to enable transcoders placement at the edge gateway 
node. 

The edge gateway node shall always send the complete list of the codec types and modes it supports for this type of call 
setup. 

UP initialisation 

The main difference compared to the Mobile to Mobile call setup is, that the CN side termination of the Gateway MGW 
(T2 in figure 6.7/1) shall start the initiahsation of the luFP according to the result of the codec negotiation. The forward 
initialisation principle shall be followed in any setup scenario. 
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6.8 



Mobile to External Network TrFO Call Establishment 
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Figure 6.8/1. Configuration during Call Setup of a Mobile to External Network Call 

The description of Figure 6.1/1 (Configuration during Call Setup of a Mobile to Mobile Call) within clause 6.1 applies 
for the network and protocol entities involved in the External Network to Mobile Call scenario with following 
modifications: 

No RNC-T is present - a party served by an external network is the terminating side of the call instead. 

The terminating side CN nodes are Gateway nodes (Gateway MSC Server/Gateway MGW). 

The Gateway MGW call context is no TrFO break equipment in general, i.e. T4 in general do not support the luFP 
framing protocol. Appropriate interworking (in some cases transcoding) has to be performed between T3 and T4. 

Therefore Figures 6.1/2 to 6.1/4. (the respective message flows for mobile to mobile call setup) apply in principle as 
well with appropriate modifications outlined below: 

Codec negotiation 

Step 1. Until 6., that give the codec negotiation phase in Figure 6.1/2, shall be applied with following modifications: 

There is no terminating UE involved in this negotiation phase. 

If the succeeding node of the Gateway MSC-Server doesn"t support OoBTC procedures for compressed voice types, the 
Gateway MSC-Server terminates the OoBTC procedures in order to enable transcoder placement at the edge gateway 
node. 

The edge gateway node should accept the Codec Type MSC-0 prefers and should not puncture out any Codec Mode. If 
TFO is to be supported then the Gateway MSC-Server shall supply the MGW with the codec list and the selected Codec 
Type in order that inband TFO negotiation may be performed. For further details see chapter 5.5. 
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6.9 Mobile to Mobile TrFO Call Establishment for GERAN lu- 
mode 
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Figure 6.9/1 : Configuration during Call Setup of a Mobile to Mobile Call for GERAN lu-mode 

The description of Figure 6.1/1 (Configuration during Call Setup of a Mobile to Mobile Call) within clause 6.1 apphes 
for the network and protocol entities involved in the Mobile to Mobile Call for GERAN lu-mode scenario with 
following modifications: 

BSC-T acts as a RNC-T. 

BSC-0 acts as a RNC-0. 

Therefore Figures 6.1/2 to 6.1/4. (the respective message flows for mobile to mobile call setup) apply as well with the 
appropriate modifications outlined below: 

Codec negotiation 

Step 1. until 6., that give the codec negotiation phase in Figure 6.1/2, shall be applied with following modifications: 

Before step 1 (BSC-0 to MSC-S-0) and step 4 (BSC-T to MSC-S-T) the RANAP Initial UE message will be sent 
indicating the GERAN capabihties, which will be available at the RAB establishment procedure. The IE describing the 
GERAN capabilities contains a list of codec types as well as the supported codec modes (for an adaptive multi-rate 
codec type), which will be available at the RAB establishment procedure. With this information the MSC Server shall 
puncture out (i.e. delete) those codec types and codec modes (for an adaptive multi-rate codec type) from the supported 
codec list taking into account the GERAN classmark and the MS capabilities which are not supported by the GERAN. 
This possibly reduced list shall be used by the MSC Server during the negotiation procedure (step 2 and step 6). For 
definition of list of supported codec types see [15]. 

The MSC-Server performs codec negotiation according to clause 5.6 with the following modifications: 

The value of the maximum number of supported codec modes shall be set to "four" (see [10]). 

RAB Assignment 

RAB Assignment shall be performed as described in clause 6.1 with following modifications: 

Additionally, the MSC Server shall include the selected codec type within RAB Assignment. 
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6.10 Relocation during TrFO towards GERAN lu-mode 
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Figure 6.10/1: Configuration during intra-MSC SRNS Relocation towards GERAN lu-mode 

The description of Figure 6.2/1 (Configuration during intra-MSC SRNS Relocation) within clause 6.2 applies for the 
network and protocol entities involved in the Relocation towards GERAN lu-mode scenario with following 
modifications: 

RAN node A either is a RNC or a BSC. In the latter case BSC-A acts as a RNC-A. 

BSC-A' acts as a RNC-A'. 

Therefore Figures 6.2/2 to 6.2/3. (the respective message flows for SRNS Relocation and TrFO) apply as well with the 
appropriate modifications outlined below: 

Relocation Initiation 

If the MSC-Server-A received the GERAN capabilities of the target cell within the RANAP Relocation Required 
message (for details when the capabilities are included see [16]), MSC-Server-A shall compare these capabilities with 
the current Selected Codec (BICC) and the Available Codecs List (BICC), taking into account Supported Codec Set 
and Active Codec Set for adaptive multimode codecs. If the GERAN capabilities in terms of codec types and modes for 
adaptive multimode codecs do not include all codes types and modes in the Available Codecs List (BICC) and all 
modes and the type of the Selected Codec (BICC), MSC Server A shall invoke the appropriate of the modification 
procedures in Section 5.8. Criteria for the selection of the appropriate procedure are given in Section 5.8. Upon 
completion of this procedure, or if no modification procedure is required, MSC server A shall proceed with the 
Relocation procedure as described in Figure 6.2/2 to 6.2/3 (Step 2. to 17.). 



RAB Assignment on the new lu leg: 

RAB Assignment on the new lu leg shall be performed as described in clause 6.2 with following modifications: 

The Relocation Request (Step 3.) contains possibly new RAB parameters depending on the actions executed as outhned 
above during the Relocation Initiation phase according to the decision on the selected codec as well as on the selected 
codec modes (for an adaptive multi-rate codec type). In addition, the MSC-Server-A shall include the selected codec 
type within Relocation Request message. For definition of hst of supported codec type see [15]. 
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6.1 1 Inter-MSC Handover during TrFO 
6.11.1 Inter-MSC Handover 

If MSC-A supports GERAN AoIP-mode then it may insert AoIP-Supported Codecs List (Anchor) (MAP) in the MAP 
Prepare Handover Request message to allow MSC-A' to use this information if target radio access is GERAN AoIP- 
mode, or during a subsequent intra-MSC handover to GERAN AoIP-mode. The detailed procedure is described in 
subclause 6.14.1. 

In order to enable the use of Tandem free and Transcoder free operation after inter-MSC handover, the procedures 
specified in 3GPP TS 23.205 [8] and 3GPP TS 23.009 [11] for "Inter-MSC Handover" shall be followed. For the 
handling of the codec lists and selected codecs the following rules apply: 

The Prepare Handover request message shall include the lu-Supported Codecs List (MAP). 

If the serving radio access is UTRAN or GERAN lu-mode, the Prepare Handover request message shall contain the lu- 
Currently Used Codec (MAP). Otherwise, if the serving radio access is A/Gb mode, the currently used codec is 
indicated by the Speech Version (Chosen) in the BSSMAP Handover Request message included in the Prepare 
Handover request message. 

If the target radio access is UTRAN or GERAN lu-mode, the Prepare Handover response message shall contain the lu- 
Selected Codec (MAP) and the lu- Available Codecs List (MAP). Otherwise, if the target radio access is A/Gb mode, 
the selected codec is indicated by the Speech Version (Chosen) in the BSSMAP Handover Request Ack message 
included in the Prepare Handover response message. 

If the target radio access is UTRAN or GERAN lu-mode, then for a speech bearer, the MSC-A server shall perform a 
call set-up with codec negotiation towards the MSC-A' server, using a Supported Codecs List (BICC) as specified in 
subclause 6.2.2. When MSC-A' receives a Supported Codecs List (BICC) with the lAM message, it shall follow the 
procedures specified in subclause 6.2.2. 

If the target radio access is GERAN A/Gb mode, then for a speech bearer the anchor MSC shall perform a call set-up 
with codec negotiation towards the target MSC, using a Supported Codec List (BICC) ordered as: 

a) optionally, the GSM codec indicated by the serving MSC during the MAP E-interface signalhng as Speech 
Version (Chosen), if it is different from list item b and if supported on Nb bearer; 

NOTE 1 : This codec can be included as the preferred codec, if MSC-A knows by means of configuration 

information that all nodes of the network support TrFO/TFO interworking and TFO, including codec 
mismatch resolution. If this codec does not match the Selected Codec (BICC), but is eventually selected 
for the network side bearer to the target MSC (MSC-A'), then either MSC-A must transcode at the anchor 
MGW or MSC-A will need to trigger a codec modification to the far end. Given that the anchor MSC 
cannot trigger all these changes at once, it must first estabhsh the network side bearer - i.e. insert a 
transcoder at the anchor MGW and then trigger the codec modification to the far end as a second step. 

b) the Selected codec (BICC), previously selected for the leg towards the far end party; 

NOTE 2: This codec is preferred, if the anchor MSC-A does not know by means of configuration information if all 
nodes in the network support OoBTC, or TrFO/TFO interworking and TFO, including codec mismatch 
resolution. This is also the best codec to be selected if the goal is to avoid additional transcoding in MSC- 
A or a codec modification from MSC-A towards the far end party. 

c) the default PCM codec; 

d) optionally, further GSM codecs that are supported by its associated MGW, e.g. the GSM codec indicated by the 
serving MSC during the MAP E-interface signalling as Speech Version (Chosen), if it is not already included 
according to list item a or b and if supported on Nb bearer; and 

e) optionally, for subsequent inter-RAT intra MSC-A" handover further codecs from the Available Codec List 
(BICC) that are applicable to other radio access types. 

For UDI/RDI multimedia calls with fallback and service change according to 3GPP TS 23.172 [17], the Supported 
Codecs List (BICC) shall contain the multimedia dummy codec and the Available Codecs List (BICC) can contain this 
codec (see [17], subclause 4.3.7). If the MSC-A server wants to establish a bearer for the multimedia dummy codec, it 
shall include this codec as the preferred codec. 
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If the target radio access is GERAN A/Gb mode and MSC-A' receives a Supported Codec List (BICC) with the lAM 
message, MSC-A' shall select a codec from this list, taking the Speech Version (Chosen) and the priorities expressed by 
the order of the codecs in the Supported Codec List (BICC) into account. 

NOTE 3: Usually, selection of the preferred codec of the Supported Codec List (BICC) will result in the best 
speech quality or best transcoder location or both; however, e.g. if MSC-A' knows by means of 
configuration information that OoBTC is not supported on some links in the network, and some nodes in 
the network are not supporting the creation of a "structured" Supported Codec List (BICC) as specified in 
subclause 9.7.2, MSC-A' can select another codec, e.g. the codec corresponding to the Speech Version 
(Chosen) or the default PCM codec. 



NOTE 4: If the procedure specified in this subclause is followed for AoIP (e.g. if the AoIP MAP codec negotiation 
is not supported by MSC-A or MSC-A'), the selection of the Speech Version (Chosen) when not the 
Selected Codec (BICC) will result in transcoding in the anchor MSC or codec modification to the far end. 
If the MSC-A' selects the preferred codec in the Supported Codec List (BICC) above and this codec is not 
equal to the Speech Version (Chosen), this will result in transcoding in the non-anchor MGW. 

If the Selected Codec (BICC) received by MSC-A in response to the BICC codec negotiation towards the target MSC 
(MSC-A') is different from the current Selected Codec (BICC) used towards the far end, the MSC-A shall insert a 
transcoder in MGW-A. 



6.1 1 .2 Codec Modification/Mid-Call Codec Negotiation after Inter-MSC 
Handover 

6.1 1 .2.1 Codec Modification/Mid-Call Codec Negotiation Initiated by the Far End Side 

If the serving radio access after inter-MSC handover is GERAN A/Gb mode, and the anchor MSC (MSC-S-A) receives 
a "Modification of Selected Codec" procedure or a "Mid-Call Codec Negotiation" procedure from the far end side the 
MAP signalhng between the anchor MSC (MSC-S-A) and the serving MSC (MSC-S-A') shall be performed only, if the 
old or the new Selected Codec (BICC) is the multimedia dummy codec. 

If both the old and the new Selected Codec (BICC) are speech codecs, the anchor MSC may terminate the codec 
modification or mid-call negotiation procedure, inserting a transcoder if required. Alternatively, the anchor MSC may 
forward the request to the serving MSC (MSC-S-A'), using the procedures as described in section 5.8. 

NOTE: The anchor MSC may decide to forward the request to the serving MSC (MSC-S-A'), e.g. when it is 

possible to (re-)establish Tandem free and Transcoder free operation end-to-end from the far end side up 
to the serving TRAU. 

If either the old or the new Selected Codec (BICC) is the multimedia dummy codec, i.e. the far end side requests a 
service change between speech and multimedia, and the Available Codecs List (BICC) previously negotiated between 
the anchor MSC and the serving MSC (MSC-S-A') indicates that the service change is supported end-to-end, the anchor 
MSC shall forward the request to modify the radio access bearer to the serving MSC (MSC-S-A') and then perform a 
codec modification or mid-call negotiation for the Nb/Nc interface towards the serving MSC (MSC-S-A'), using the 
procedures as described in section 5.8. If the service change between speech and multimedia cannot be performed 
successfully, the anchor MSC shall reject the request for codec modification or mid-call negotiation towards the far end 
party. 

6.1 1 .2.2 TFO Codec Mismatch Resolution in the Serving MSC 

If the serving radio access after inter-MSC handover is GERAN A/Gb mode, and TrFO has been established between 
the anchor MSC and the serving MSC, the serving MSC may detect a TFO codec mismatch between the Selected 
Codec (BICC) used on the TrFO link and the GSM speech codec chosen by the serving BSC. 

If the serving MSC supports the codec mismatch resolution procedure (see 3GPP TS 28.062 [10], subclause 6.3) and 
wants to change the Selected Codec (BICC) due to this procedure, the serving MSC shall initiate a codec modification 
or mid-call codec negotiation procedure towards the anchor MSC as described in sections 5.8.1, 5.8.2 and 5.8.3. 
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In the event of a collision of codec modification/mid-call codec negotiation procedures initiated by the anchor MSC and 
the serving MSC, the procedures described in Q. 1902.4, subclause 10.4.7.5 [6] shall apply, with the following 
modification of the first sentence in subclause 10.4.7.5 [6], list item 2: 

Codec modification/mid-call codec negotiation requests initiated in the direction towards the serving MSC shall take 
precedence over codec modification/mid-call codec negotiation requests initiated in the direction towards the anchor 
MSC. 

6.1 1 .2.3 Modification Procedure after Codec Change in the Serving MSC 

The procedures as specified in section 6.2.3.3 apply. 



6.12 Incoming data call from PSTN 



For incoming calls from PSTN, the TMR may not allow to identify the requested service, since the same value may be 
used to identify both voice and data calls. 

6.12.1 Identification of data call at Visited MSC 

An incoming data call from the PSTN may be identified as data call using signalhng interaction with the terminating 
UE at the Visited MSC. The following procdures are recommended in a network supporting TrFO to allow the Visited 
MSC to identify the data call using interactions with the terminating UE: 

The GMSC includes a G.71 l(and possibly other codecs) in the BICC supported codec list. 

If the Visited MSC determines that an incoming call is a data call, it shall select G.71 1 as codec. 

Note: A 64 kbit/s bearer, as required for data calls, will be set up if G.71 1 is selected. 



UE 


PUVIN-BC 


V_MSC 


lAM (codec list : coded, codec 2, G711, 
"nv|R=3,lKHz) 


G_MSC 


lAM ("nv|R=3,lKhz) 
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TDM ) 














^ Packet backbone ^^ 


MGW 




MGW 













Figure 6.1 2.1/1 .Identification of incoming data call at Visited MSC 

6.12.2 Handling at transit exchange in inhomogenous networks 

If a transit exchange connecting a packet backbone and a TDM backbone in an inhomogenous network is not able to 
determine if an incoming call from the packet backbone side is a data call or a speech call (e.g. TMR=3.1kHz is 
received), it may select G.711 as codec to enable possible data calls. 

Note: A 64 kbit/s bearer, as required for data calls, will be set up if G.71 1 is selected. 
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Figure 6.1 2.2/1. JHandiing of possible data call at transit exchange between TDM and packet backbone 

6.12.3 Identification of data call at G-MSC using multi-numbering 

If the called mobile subscriber is configured with multinumbering service, the GMSC may use the GSM Bearer 
Capabihty that may be received from the HLR during the Send Routing Information procedure to identify the requested 
service and select directly a codec transparent for data call. It may also pass the bearer capabihty information to 
subsequent nodes to allow them to select a codec transparent for data call as well (see 3GPP TS 29.007 [19]). This may 
be particularly usefull in configurations where the terminating MSC does not participate to the codec negotiation 
procedure, as illustrated in figures 6.12/1 and 6.12/2. 




Figure 6.1 2.3/1. Use of the GSM Bearer Capability by TDM GMSC for incoming data call from PSTN 
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Figure 6.12.3/2.Use of the GSM Bearer Capability by GMSC for incoming data call from PSTN 

6.13 Mobile to Mobile TrFO Call Establishment in GERAN AolP 
mode 



MSC Server -T 



MSC Server - O 



BSC-T 



BSSAP - - 



BSSAP 



TICC 



Nc 



TICC 



inter working 



BSSAP 



-Mc 



RTP 

term.T 



AolP 



MGW-T 

r 1 

I I 

i-T-;-- 

-O-i-(RTP-RAN) 



MGW-0 I 

T" 



BSC-0 



___J 

T2 

(Nb-CN) 



J 



KD Of 

Nb 



T3 

(Nb-CN) 



1 

I 
L 

! T4 

■V(RTP-RAN) 



1<^ \ 

AolP 



BSSAP 



RTP 
term .q 



TrFO Relation between BSC-0 o BSC-T (after call setup) 



Figure 6.13/1 : Configuration during Call Setup of a Mobile to Mobile Call in GERAN AolP mode 

Figure 6.13/1 shows the configuration for mobile to mobile call establishment in GERAN AolP mode. 

Following network and protocol entities are involved in the scenario, outlined in Figure 6.z/l: 

BSC-T, BSC-O: terminating/originating BSCs. 

MSC Server-T, MSC Server-O: MSC Servers, performing service, i.e. codec negotiation. 

MGW-T, MGW-O: terminating/originating MGWs. 

BSSAP, TICC:C-plane protocol incarnations, responsible for codec negotiation, controlling the respective interfaces 
(A, Nc), creating, modifying, removing etc. terminations and contexts. 

NOTE: The following sequences are examples, further detailed call flows are described in TS 23.205 [6]. 
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Figure 6.13/2: Call Setup. Mobile to Mobile Call in GERAN AolP mode. Message Flow part 1 
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Figure 6.13/3: Call Setup. Mobile to Mobile Call in AolP mode. Message Flow part 2 
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Figure 6.13/4: Call Setup. Mobile to Mobile Call in AolP mode. Message Flow part 3 

Codec negotiation 

Steps 1. to 8. give the codec negotiation phase. The BSCs inform the MSC servers their capabihties (1. and 5.). The 
mobiles inform the network about their capabihties (2. and 6.). The MSC-Server performs codec negotiation according 
to clause 5.6. 

Assignment procedure 

RAN side terminations have to be seized (9. and 17.) before sending Assignment Request message (steps 10. and 18.). 
Assignment Request message contains the MSC server preferred codec list. BSC retains the decision to choose the final 
codec for the radio access and informs the MSC server about the codec to be used in the radio access in Assignment 
Complete message. Step 20 may then be required to modify the selected codec (SDP) if different from the preferred 
codec included at step 17. 

NOTE: The BSC should offer codecs that it can support for the call and should therefore under normal 
circumstances select the MSC preferred codec. 

6.14 Handover in GERAN AolP mode during TrFO 
6.14.1 Inter-MSC Handover in GERAN AolP mode 

The following figures are describing inter-MSC handover in GERAN AolP mode. 
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Figure 6.14/1: Configuration during inter-MSC Handover in GERAN AolP mode 
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Figure 6.14/1 shows the configuration during inter-MSC Handover in GERAN AoIP mode. After setting up the new 
AoIP interface (towards BSC-A') until releasing the old one, the original TrFO relation (A<^B) and the target TrFO 
relation (A'<^B) exist in parallel. Within the respective contexts interworking between T4 and T5 at MGW-A' and Tl, 
T2 and T3 at MGW-A are necessary: 

T3 (MGW-A) shall perform initiahsation towards MGW-A'. 
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Figure 6.14/2: Inter-MSC Handover in GERAN AoIP mode and TrFO. Flow chart part 1 
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Note: There can be interim network transit nodes between IVISC-A and IVISC-A' 

Figure 6.14/3: Inter-MSC Handover in GERAN AolP mode and TrFO. Flow chart part 2 

MAP signalling for handover and codec negotiation 

The MSC-A server may include an AoIP-Supported Codecs List (Anchor) (MAP) in the MAP Prepare Handover 
request if MSC-A supports GERAN AoIP mode. Only GSM codecs supported both by the UE and by the anchor MSC 
may be included in this hst. The codec capabilities of the serving radio access, i.e. the radio access used prior to the 
inter-MSC handover or relocation, need not be taken into account. 

The anchor MSC-A may decide to include in the AoIP-Supported Codecs List (Anchor) (MAP) only codecs that are 
also included in the Available Codecs List (BICC) or that are TrFO compatible to codecs in this list. 
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NOTE 1 : The codec types listed in the Channel Type Information Element are the full list of codec types supported 
by the UE (as recognised by the Anchor MSC); this list is not affected by the Available Codecs List 
(BICC) or any resultant AoIP- Supported Codecs List (Anchor) (MAP) IE. 

NOTE 2: If the Available Codecs List (BICC) is kept up-to-date by the far end side by means of modifications of 
the Available Codecs List (BICC), and the target BSC selects one of the codecs from this list, it may be 
possible to achieve TrFO after the inter-MSC handover by performing a codec modification to the far end 
instead of a mid-call codec negotiation. 

When selecting the order of priority for the codecs within the AoIP-Supported Codecs List (Anchor) (MAP), MSC-A 
shall take the Selected Codec (BICC) and the Available Codecs List (BICC) negotiated with the far end party into 
account. 

- If it is desired to achieve immediate TrFO upon completion of the inter-MSC handover, then the MSC-A server 
shall include the codec type and configuration of the Selected Codec (BICC) negotiated with the far end or a 
TrFO compatible codec type and configuration as preferred codec in the AoIP-Supported Codecs List (Anchor) 
(MAP). 

- If the anchor MSC-A prefers a codec different from the Selected Codec (BICC), then the MSC-A server shall 
include this other codec as the preferred codec in the AoIP-Supported-Codecs List (Anchor) (MAP). If the 
preferred codec is selected by the target BSC, transcoding will be required after the inter-MSC handover. The 
location of the transcoder will be determined during the network side codec negotiation. 

NOTE 3: The anchor MSC-A can select the second alternative e.g. if a subsequent codec modification or mid-call 
codec negotiation towards the far end is intended. 

If the target MSC-A' receives the AoIP-Supported Codecs List (Anchor) (MAP) and supports AoIP codec selection 
based on this list, it shall remove from the AoIP-Supported Codecs List (Anchor) (MAP) and from the BSSMAP 
Channel Type IE any codecs not supported by its own MGW-A' or by local pohcy. MSC-A' shall include the remaining 
codecs in the MSC Preferred Codec List (BSSMAP). 

MSC-A' shall ensure consistency between the contents of the MSC Preferred Codec List (BSSMAP) and the BSSMAP 
Channel Type IE sent to the target BSS (see 3GPP TS 48.008 [15], subclause 3.2.1.8). To this purpose MSC-A' may 
add codecs to the MSC Preferred Codec List (BSSMAP), if the codec type is also included in the Channel Type IE. For 
the added codecs MSC-A' shall select a codec configuration supported by MGW-A' and according to preferences 
configured locally in the target MSC-A'. MSC-A' shall remove any codec types from the BSSMAP Channel Type IE 
that are not included in the resultant MSC Preferred Codec List (BSSMAP). 

If MSC-A does not include an AoIP-Supported Codecs List (Anchor) (MAP) in the MAP Prepare Handover request 
then MSC-A' shall proceed with the handover as described in subclause 6.1 1.1. 

MSC-A' shall include in the MAP Prepare Handover response the AoIP-Selected codec (Target) (MAP) and the AoIP- 
Available Codecs List (MAP), i.e. the BSS Supported Codecs hst returned by BSS-A', if: 

- the target access is GERAN AoIP mode; 

- the target MSC received the AoIP-Supported Codecs List (Anchor) (MAP) in MAP Prepare Handover Request; 
and 

- the target MSC supports AoIP codec selection based on the received AoIP-Supported Codecs List (Anchor) 
(MAP). 

If MSC-A' does not include the AoIP-Selected Codec (Target) (MAP) and the AoIP- Available Codecs List (MAP) lEs 
in the MAP Prepare Handover response, both MSC-A and MSC-A' shall proceed as described in subclause 6.1 1.1. 

Network side bearer establishment and codec handling 

The handling of the bearer establishment between MSC-A and MSC-A' shall be performed as for a normal call with 
OoBTC. For a speech bearer, the MSC-A server shall perform a call set-up with codec negotiation towards the MSC-A' 
server, using a Supported Codec List (BICC) containing: 

a) optionally, the AoIP-Selected Codec (Target) (MAP) (negotiated with MSC-A' during the MAP E-interface 
signalhng), if it is not already included according to hst item b; 
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NOTE 3: This codec can be included as the preferred codec, if MSC-A knows by means of configuration 

information that all nodes of the network support TrFO/TFO interworking and TFO, including codec 
mismatch resolution. If this codec does not match the Selected Codec (BICC), but is eventually selected 
for the network side bearer to the target MSC (MSC-A'), then either MSC-A must transcode at the anchor 
MGW or MSC-A will need to trigger a codec modification to the far end. Given that the anchor MSC 
cannot trigger all these changes at once it must first establish the network side bearer - i.e. insert a 
transcoder at the anchor MGW and then trigger the codec modification to the far end as a second step. 

b) the Selected codec (BICC), previously selected for the leg towards the far end party; 

NOTE 4: This codec is preferred, if the anchor MSC-A does not know by means of configuration information if all 
nodes in the network support OoBTC, or TrFO/TFO interworking and TFO, including codec mismatch 
resolution. This is also the best codec to be selected if the goal is to avoid additional transcoding in 
MSC-A or a codec modification from MSC-A towards the far end party. 

c) the default PCM codec; 

d) optionally, further codecs from the AoIP-Supported Codecs List (Anchor) (MAP) that are applicable to the target 
radio access, e.g. the AoIP-Selected Codec (Target) (MAP), if it is not already included according to list item a 
or b; and 

e) optionally, for subsequent inter-RAT intra MSC-A" handover further codecs from the Available Codec List 
(BICC) that are applicable to other radio access types. 

For UDI/RDI multimedia calls with fallback and service change according to 3GPP TS 23.172 [17], the Supported 
Codecs List (BICC) shall contain the multimedia dummy codec and the Available Codecs List (BICC) can contain this 
codec (see [17], subclause 4.3.7). 



If MSC-A' receives a Supported Codec List (BICC) with the lAM message, MSC-A' shall select a codec from this list, 
taking the AoIP-Selected codec (Target) (MAP) and the priorities expressed by the order of the codecs in the Supported 
Codec List (BICC) into account. 

NOTE 5: Usually, selection of the preferred codec of the Supported Codec List (BICC) will result in the best 
speech quality or best transcoder location or both; however, e.g. if MSC-A' knows by means of 
configuration information that OoBTC is not supported on some links in the network, and some nodes in 
the network are not supporting the creation of a "structured" Supported Codec List (BICC) as specified in 
subclause 9.7.2, MSC-A' can select another codec, e.g. the AoIP-Selected codec (Target) (MAP) or the 
default PCM codec. 

If MSC-A' selects a codec different from the AoIP-Selected codec (Target) (MAP) or if MSC-A' receives an lAM 
message without a Supported Codec List (BICC), MSC-A' shall insert a transcoder in MGW- A'. 

If the Selected Codec (BICC) received by MSC-A in response to the BICC codec negotiation towards the target MSC 
(MSC-A') is different from the current Selected Codec (BICC) used towards the far end, the MSC-A shall insert a 
transcoder in MGW-A. 

Subsequent inter MSC handover to a third MSC 

The anchor MSC (MSC-A) server may include AoIP-Supported Codecs List (Anchor) (MAP) in the MAP Prepare 
Handover request towards the third MSC. 



7 Interactions with supplementary services 

7.1 Call Deflection service (GSM 23.072) 

In order to apply the confirmation tone to the originating party, the speech insertion procedure described in clause 6.3 is 
applied. 
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7.2 Line identification services (GSM 23.081 ) 

7.2.1 Calling Line Identification Presentation (CLIP) 

No impact. 

7.2.2 Calling Line Identification Restriction (CLIR) 

No impact. 

7.2.3 Connected Line Identification Presentation (COLP) 

No impact. 

7.2.4 Connected Line Identification Restriction (COLR) 

No impact. 

7.3 Gall forwarding services (GSM 23.082) 

7.3.1 Call Forwarding Unconditional (CPU) 

In order to apply the confirmation tone to the originating party, the speech insertion procedure described in clause 6.3 is 
apphed. 

7.3.2 Call Forwarding on mobile subscriber Busy (CFB) 

In order to apply the confirmation tone to the originating party, the speech insertion procedure described in clause 6.3 is 
apphed. 

7.3.3 Call Forwarding on No Reply (CFNRy) 

In order to apply the confirmation tone to the originating party, the speech insertion procedure described in clauses 6.3 
is applied. 

7.3.4 Call Forwarding on mobile subscriber Not Reachable (CFNRc) 

In order to apply the confirmation tone to the originating party, the speech insertion procedure described in clauses 6.3 
is applied. 

7.4 Call wait (GSM 23.083) 

In order to apply the notice tone to the interjected party, the speech insertion procedure described in clause 6.4 is 
applied. 

7.5 Gall hold (GSM 23.083) 

In order to apply the notice tone to the held party, the speech insertion procedure described in clause 6.4 is applied. 

7.6 Multiparty (GSM 23.084) 

In order to mix calls, the speech insertion procedure described in clause 6.4 is applied. 
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7.7 Closed user group (GSM 23.085) 

No impact. 

7.8 Advice of charge (GSM 23.086) 

No impact. 

7.9 Userto-user signalling (GSM 23.087) 

No impact. 

7. 10 Gall barring (GSM 23.088) 

7.10.1 Barring of outgoing calls 

No impact. 

7.10.2 Barring of incoming calls 

No impact. 

7.1 1 Explicit Call Transfer (GSM 23.091) 

In case that a call A-B is transferred to C by B (A-C as result), A-B may use codec x, A-C may use codec y, the 
procedure described in clause 6.3 is applied. 

7. 1 2 Completion of Calls to Busy Subscriber (3G TS 23.093) 

Within CCBS there exists an option for CCBS calls where a bearer can be established before setup in the 
state "CC-establishment confirmed". If the selected codec after setup is different to the one which was used to establish 
the bearer, RAB assignment (modify) may be required when RAB parameters are different. 

8 Charging 

The selected codec shall be included in all the call data records of the call legs involved in out-band codec negotiation 
belonging to a particular subscriber. 



Codec Negotiation For SIP-I on No 



9.1 General 

Codec negotiation procedures for SIP-I are described in the following subclauses, where additions or exclusions to the 
general procedures and principles described in the previous clauses for BICC are required; otherwise it shall be assumed 
that the others clauses in this specification shall apply to SIP-I on Nc. Normal call handling procedures for SIP-I on Nc 
are described in 3GPP TS 23.231 [20]. 

SIP-I codec negotiation procedures defined in the present specification extend the normal Offer/ Answer rules defined 
by IETF RFC 3264 [24]. In order to identify the compliance to these enhancements, the 3GPP OoBTC Indicator is 
defined, see 3GPP TS 29.231 [21]. 
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NOTE: Non-speech RTP payload types may also need to be negotiated within the offer/answer procedures , e.g. 
the Telephony Event RTP payload type or the ClearMode codec. This is further described in specific 
clauses in other specifications such as 3GPP TS 23.231 [20] and 3GPP TS 29.007 [19]. 

9.2 Framing Protocol 

SIP-I user plane does not use luFP framing protocol or associated 3GUP procedures. Rate control procedures are 
performed within RTP. 

9.3 Basic Procedures 

9.3.0 Applicability 

The procedures in the subsequent subclauses 9.3.1 to 9.3.4 are applicable for speech calls and SCUDIF calls. 
Procedures for SCUDIF calls are further specified in 3GPP TS 23.172 [17]. Procedures to establish data calls are 
specified in 3GPP TS 23.231 [20] and 3GPP TS 29.007 [19]. 

NOTE: For SCUDIF, a Multimedia Dummy Codec is offered together with a speech codec in a single SDP m- 
line. 

If an offerer is not able to determine if a call is a data call or a speech call, it shall only offer speech codecs including 
the PCM codec and apply the procedures in subclause 6.12. If codecs other than PCM are also offered, it shall also 
apply the procedures specified in subclauses 9.3.1 to 9.3.4. 

9.3.1 3GPP Node Originating SDP Offer 

- An MSC-S initiating an offer shall include the OoBTC Indicator in the offer. 

- If the offering MSC-S receives an answer without the OoBTC Indicator, the codec list shall be interpreted in 
accordance with the IETF codec rules. If the answer contains multiple codecs, the MSC-S shall initiate a second 
offer with the selected codec and may include the OoBTC Indicator or leave it out. 

- If the offering MSC-S receives an answer with the OoBTC Indicator, then the codec list contains the 3 GPP 
Selected Codec and Available Codec List and shall be interpreted to be in accordance with the codec negotiation 
procedures described in this specification. 



9.3.2 3GPP Node Terminating SDP Offer 

- If the 3GPP MSC-S terminating the codec negotiation receives an offer with the OoBTC Indicator, it shall 
include the OoBTC Indicator in the Answer. The returned codec list shall be formatted as a 3 GPP Selected 
Codec List and Available Codec List. 

- If the 3GPP MSC-S terminating the codec negotiation receives an offer without the OoBTC Indicator, the codec 
list shall be interpreted in accordance with the IETF codec rules and the MSC-S shall initiate an answer with a 
single codec. It may include the OoBTC Indicator in the Answer or leave it out. 

9.3.3 3GPP Intermediate Node Receiving SDP Offer 

- A 3 GPP intermediate node receiving an offer with the OoBTC Indicator shall forward the OoBTC Indicator in 
the Offer to the succeeding node. 

- A 3 GPP intermediate node receiving an offer without the OoBTC Indicator shall behave according to two 
options dependent on implementation option: 

1. The 3 GPP intermediate node may forward the (IETF type) codec hst to the succeeding node without the 
OoBTC Indicator. 

2. The 3GPP intermediate node may include the OoBTC indicator in the offer it sends to the succeeding node. 
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NOTE: The intermediate node may forward an INVITE for a call that was initiated by the external network 
(External NW -> intermediate node(s) -> external NW), in which case the offer received from the 
preceding node may not contain the OoBTC Indicator. 

9.3.4 3GPP Intermediate Node Receiving SDP Answer 

- A 3 GPP intermediate node receiving an answer with the OoBTC Indicator shall behave according to the 
presence of the OoBTC Indicator in the initial offer received from the preceding node. 

1. If the Initial Offer included the OoBTC Indicator, the 3 GPP intermediate node shall forward the Answer with 
the OoBTC Indicator to the preceding node. The codec hst shall be formatted as a 3GPP Selected Codec and 
Available Codec List. 

2. If the Initial Offer did not include the OoBTC Indicator, the 3GPP intermediate node shall forward the 
Answer without the OoBTC Indicator to the preceding node. The answer shall contain a single codec 
(mapped from the 3GPP Selected Codec). 

- A 3 GPP intermediate node receiving the answer with multiple codecs and without the OoBTC Indicator shall 
behave according to the three options below, dependent on implementation option: 

1. The 3 GPP intermediate node may forward the (IETF type) codec list to the preceding node, regardless of 
whether the preceding node included the OoBTC Indicator in the offer. The answer shall not contain the 
OoBTC Indicator. 

NOTE: This may be permitted when the intermediate node can support multiple speech codecs during a 
given session; if this is not the case then option 3 shall be performed. 

2. If the initial offer received by the intermediate node contained the OoBTC Indicator, the 3 GPP intermediate 
node may map the (IETF type) codec hst into a 3GPP Selected Codec and Available Codec List and forward 
this to the preceding node with the OoBTC Indicator. This exchange concludes the offer/answer from the 
perspective of the preceding node. If the answer contains multiple codecs, the 3GPP intermediate node shall 
initiate a second offer toward the succeeding node with a single codec (same as the 3GPP Selected Codec) 
without the OoBTC Indicator. 

3. If the initial offer received by the intermediate node did not contain the OoBTC Indicator the 3 GPP 
intermediate node may signal back to the preceding node a single codec (it shall select the most appropriate 
codec from the list of received codecs). This exchange concludes the offer/answer from the perspective of the 
preceding node. The 3GPP intermediate node shall initiate a second offer toward the succeeding node with a 
single codec (same as the 3GPP Selected Codec) without the OoBTC Indicator. 

9.4 Semantics of 3GPP OoBTC Indicator 

After the 3GPP OoBTC Indicator has been negotiated, i.e. the 3GPP OoBTC indicator has been included in both SDP 
offer and corresponding SDP answer the following rules apply, for both offerer and answerer: 

- A change from the Selected Codec to a codec within the Available Codec List (ACL) in the answer, is only 
permitted using a new SDP offer-answer exchange to re-negotiate the Selected Codec. Inband switching of 
speech codec types (by sending the new codec with corresponding RTP payload type) is not permitted, and no 
resources for these codecs need to be reserved e.g. at a MGW. 

- Codecs in the Available Codec List indicate codecs that are supported. This information may be used by an MSC 
to decide if a change of the Selected Codec to some other codec using a new SDP offer-answer exchange is 
attempted. 

NOTE: The Available Codec List may be used by a (G)MSC as decision criterion if a codec re-negotiation is 
attempted. However, this does not preclude that an (G)MSC offers codecs not included in the previous 
ACL in a codec re-negotiation. 

- A change from the Selected Codec in the answer to an "auxihary" payload type within the answer, i.e. the RTP 
Telephony Event (see IETF RFC 4733 [22]) or the comfort noise codec (see IETF RFC3389 [yx]), and vice 
versa is permitted without new SDP offer-answer exchange by "Inband" switching, i.e. by simply sending the 
other RTP payload type. 
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9.5 Handling of Auxiliary Payload types 

If auxiliary payload types are negotiated the MSC Server shall configure the MGW to support the multiple payload 
types for a given termination/stream where apphcable (i.e. for speech codec and for RTP Telephony Event and/or 
comfort noise codec) with the following condition: 

- Resources for a possible comfort noise codec (RFC3389) within the answer codec shall only be reserved in the 
MGW by the MSC Server if the comfort noise codec (RFC3389) is applicable for the selected codec. For 
instance, AMR does contain an internal comfort noise mode and is not used in combination with the comfort 
noise codec (see IETF RFC3389 [23]). 

9.6 Codec Negotiation Example Sequences 

The following figures show examples of codec negotiation for a selection of common call scenarios to highlight the 
principles agreed in the preceding clause; the sequences are not exhaustive. 
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Figure 9.6.1 : Mobile Originating Codec Negotiation 
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Figure 9.6.2: Mobile Terminating Codec Negotiation - External Node supports OoBTCIndicator 
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Figure 9.6.3: Mobile Terminating Codec Negotiation - External Node does not support 

OoBTCIndicator 
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Figure 9.6.4: Codec Negotiation during call forwarding outside of PLMN - external Incoming node 

does not support 3G OoBTCIndicator 
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Figure 9.6.5: Codec Negotiation during call forwarding outside of PLMN - external node supports 3G 

extension 
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Figure 9.6.6: Mobile Originating Codec Negotiation witli specific codec examples 
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Figure 9.6.7: Mobile Terminating Codec Negotiation with specific codec examples 



9.7 



Codec Lists Structure 



9.7.1 General 

The following are rules that are applied when populating a Session Description Protocol (SDP) media offer or an SDP 
media answer for 3 GPP SIP-I OoBTC. A SIP-I signalling endpoint shall initiate an SDP Offer/ Answer exchange during 
call establishment and may initiate an SDP Offer/ Answer exchange at any time that the bearer configuration changes, 
e.g., during handover or invocation of a supplementary service such as 3pty. 

9.7.2 Rules for Constructing an Offer 

The Codec List/SDP in the Offer shall contain codecs/payload types defined as follows: 

"Direct Codec" payload types that can be used between bearer endpoints without any additional transcoding 
stage; 

- "Indirect Codec" payload types that can be used between bearer endpoints with an additional transcoding stage; 
and 

- "Auxiliary" payload types unrelated to the primary codec selection process may be included. 

The Offered Codec List shall contain two sub-lists ordered as: zero or more "Direct Codecs" plus zero or more 
"Indirect Codecs". A list of zero or more "auxiliary" payload types, e.g., RTP Telephony Events, CN (comfort noise), 
which are not used in the process of selecting the primary codec, may follow after the direct and indirect codec types. 

The direct and indirect codec sub-hsts shall be ordered in decreasing preference. 
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G.71 1 shall always be included either as direct or indirect codec. When present, the indirect codec sub-list shall always 
start with G.71 1, if G.71 1 is not a direct codec. However, an entry for G.71 1 shall appear only once in the offered codec 
hst. 

The offer may contain a hst of several direct and indirect codec types. 

NOTE: These rules for constructing an SDP Offer enable TrFO in the network by assuring that the network 

configures the minimum number of transcoders for each session. These rules are needed to enable TrFO 
in the network and are consistent with IETF RFC 3264 [24], but are not part of IETF RFC 3264 [24]. 
Other SIP endpoints may not follow the same conventions for prioritizing codecs. As an exception to the 
aforementioned rules, the offerer could choose to construct an Offered Codec List in a different order 
from the one described in the above rules, but this is not recommended as the answerer may select a 
codec that does not minimize the number of transcoders for the session and does not enable TrFO. 

9.7.3 Rules for Constructing an Answer 

The answering signalhng endpoint shall, before processing the Offer and before populating the Answer, structure the 
available codec types on its access into "Direct Codecs," "Indirect Codecs", and "auxiliary" payload types. 

The answering signalling endpoint shall then take both structured Codec Lists, the one received in the Offer and the one 
created locally, into account and shall select the "optimal" codec type for the Answer, which shall be the first codec type 
in the Answer; the Selected Codec. The Answer shall contain at least one direct or indirect codec from among those 
hsted in the Offer. The criteria for selecting the "optimal" codec may depend on operator choices and preferences (local 
pohcy), such as Speech Quality, Bit Rate on transport or DSP load (for transcoding) or other. 

If the Answer to a subsequent Offer comprises all or a subset of the Direct and Indirect codecs in the preceding Answer 
within the dialog, then the IP address, and port information in the SDP Answer should remain the same. 

Ideally the Selected "optimal" Codec is a direct codec type on both accesses, which results in no transcoding being 
necessary. 

9.8 Void 
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Annex A (informative): 
Codec Re-negotiation 



A node may perform a procedure (e.g. handover) that results in a completely new list from that which was originally 
negotiated. Assuming that the current Selected Codec is still common (no Selected Codec Modification or re- 
negotiation) then the node shall send a Re-negotiation Request with the new Supported Codec List. The Supported 
codec hst may then be punctured by nodes in the network in the same was as for the basic Codec Negotiation procedure 
and a new Available Codecs List returned. 

If a node performs a procedure (e.g. handover) that results in both a completely new list and also the need for a new 
codec then Codec Re-negotiation may be performed with a request for a new codec selection. The procedure is then the 
same as for an initial codec negotiation. 
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Annex B (normative): 
Wideband Speech Service 

Support Of WB speech service 



Several compatible Codec Types to enable wideband (WB) speech service are defined in 3G TS 26.103 v.5.0.0. Support 
of these Codec Typess by a UE is indicated to the MSC by inclusion in the Supported Codecs IE. Note, for GERAN 
there is also a specific classmark, which includes the radio access" support of WB Codec Typess. Normal TrFO 
signalling shall apply, where wideband Codec Types may be given preference in the codec list if the wideband service 
is available to that user. 

Call Establishment 

Where end-to-end TrFO cannot be achieved (e.g. the external network does not support OoBTC procedures) a decision 
whether to accept the WB codec type at the interworking point and transcode to narrowband PCM (G.71 1) or to 
remove the wideband codec type from the codec list and only allow narrowband service to continue has to be made. The 
decision making factors are: 



i) Is TFO supported? TFO allows the WB service to be negotiated inband and if successful allow end-to-end 

WB speech. 

ii) If TFO is supported then a NB speech Codec Type may be selected as the initial codec type. If the TFO 

inband protocol resolves that end-to-end WB speech is possible then mid-call codec 

negotiation/modification procedures shall be employed to switch to WB service. Alternatively if AMR-WB 
is proposed then codec modification will be required if TFO can be successful in NB but cannot be 
successful in WB. The decision on which Type to select initially should be based on the probability of 
acceptance of the service. 

iii) Which WB Codec Modes shall be permitted? AMR-WB has 3 mandatory modes for all RANs (6.60, 8.85, 

12.65) and 2 optional modes for UTRAN & GERAN-8PSK_FR (15.85, 23.85). If transcoding from a WB 
mode to G.71 1 then only narrowband speech quahty will result. Therefore no gain is obtained by allowing 
the higher modes whereas additional radio access bandwidth is used. 

iv) Decision rules for codec type selection and AMR-WB codec mode selection are described in TFO 

specification TS 28.062. 

V) 

vi) Is charging apphed to use of higher modes? 

Note: Transcoding between WB source encoding and default PCM/G.71 1 provides similar quality (but no 

better) as would be achieved by NB source encoding. Thus in many cases avoiding modification back to 
NB codec (when TrFO cannot be achieved) is preferred. On the other hand the WB Codec Types require 
shghtly higher bit rates and thus are shghtly less error robust. 

Handover between WB and NB speech 

Handover of a successfully estabhshed WB speech call to a radio access that cannot guarantee the support of WB 
speech again requires a decsion whether to transcode or modify. 

If the call has been established end-to-end in WB TrFO, or end-to-end in WB quality including TFO links, then a 
modification to NB speech on the TrFO link may be preferrable - to avoid inserting of 2 transcoders (one transcoding 
between WB speech and NB speech). It depends on the possibility to get WB TFO support on that NB radio access. In 
general the same decision rules apply as for call estabhshment described above. 



Interworking with external networks (PSTN/ISDN) 

In ITU-T a WB speech codecalgorithm is defined based on the 3GPP AMR-WB codec algorithm: G.722.2. 
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Note: It is desired that all Codec Types based on that WB algorithm are exactly compatible with the 3GPP 

AMR-WB Codec Types to enable end-to-end WB speech between fixed and mobile. This means that all 
configuration parameters must be compatible, for example codec mode change in sending direction 
(encoder side) should adhere to the 40ms interval required for GERAN radio access. 

Provided that G.722.2 is directly compatible interworking to external networks should indicate support for this codec 
type in the Supported Codec List when AMR-WB codec is received from the UE. Receipt of G.722.2 from an external 
network shall be translated to support of AMR-WB by the PLMN nodes. 

Multi-party Calls 

A decision whether to modify any WB legs to NB source encoding may be made based on similar decisions as for the 
call establishment when TrFO is not successful. 

Note: The conference bridge is assumed to convert any WB call leg into NB speech. Calls established in WB 
that result in subsequent parties being joined in conference or calls being established toward a specific 
conference bridge will under the existing conferencing technology result in NB speech quality. 



Lawful Interception 

Lawful Interception of AMR WB speech service shall be in accordance with clause 4.3. 
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